Здравствуйте, eao197, Вы писали:
E>Nice -- не функциональный язык программирования.
Гм...
Для тех, кто интересуется фактами, приведу пример кода на нефункциональном языке Nice
<T, U, V> T->U->V curry((T,U)->V func) = T parm1 => U parm2 => func(parm1, parm2);
void main(String[] args) = println(curry((int a, int b) => a + b)(2)(2));
C:\Nice>nicec -a curry.jar curry
nice.lang: parsing
curry: parsing
curry: typechecking
curry: generating code
curry: linking
curry: writing in archive
nice.lang: writing in archive
C:\Nice>java -jar curry.jar
4
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Nice -- не функциональный язык программирования.
K>Гм...
K>Для тех, кто интересуется фактами, приведу пример кода на нефункциональном языке Nice K>
K><T, U, V> T->U->V curry((T,U)->V func) = T parm1 => U parm2 => func(parm1, parm2);
K>void main(String[] args) = println(curry((int a, int b) => a + b)(2)(2));
K>
Ну а паттерн-матчинг где?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
K>>Для тех, кто интересуется фактами, приведу пример кода на нефункциональном языке Nice K>>
K>><T, U, V> T->U->V curry((T,U)->V func) = T parm1 => U parm2 => func(parm1, parm2);
K>>void main(String[] args) = println(curry((int a, int b) => a + b)(2)(2));
K>>
E>Ну а паттерн-матчинг где?
Где имение? Где вода? Есть мнение, причем не только мое, что для того, чтобы язык являлся функциональным необходимы и достаточны функции, как первоклассные объекты, а значит и функции высокого порядка. И то и другое я продемонстрировал.
Quod erat, как говорится, demonstrandum.
Далее спор может продолжаться только как терминологический.
... << RSDN@Home 1.2.0 alpha rev. 726>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Гм...
K>Для тех, кто интересуется фактами, приведу пример кода на нефункциональном языке Nice K>
K><T, U, V> T->U->V curry((T,U)->V func) = T parm1 => U parm2 => func(parm1, parm2);
K>void main(String[] args) = println(curry((int a, int b) => a + b)(2)(2));
K>
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
K>>>Для тех, кто интересуется фактами, приведу пример кода на нефункциональном языке Nice K>>>
K>>><T, U, V> T->U->V curry((T,U)->V func) = T parm1 => U parm2 => func(parm1, parm2);
K>>>void main(String[] args) = println(curry((int a, int b) => a + b)(2)(2));
K>>>
E>>Ну а паттерн-матчинг где?
K>Где имение? Где вода? Есть мнение, причем не только мое, что для того, чтобы язык являлся функциональным необходимы и достаточны функции, как первоклассные объекты, а значит и функции высокого порядка. И то и другое я продемонстрировал. K>Quod erat, как говорится, demonstrandum. K>Далее спор может продолжаться только как терминологический.
А как же немутабельные объекты?
А как же все возвращает значение? Скажем if в Scala и OCaml имеет свое значение и можно написать что-то типа:
let x = if( a ) b else c
А пример, приведенный вашему, можно и на D 2.0 изобразить, там уже замыкания есть. Так что, D уже функциональным языком стал?
Да и сам автор не причисляет Nice к функциональным языкам.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, Klapaucius, Вы писали:
K>>Гм...
K>>Для тех, кто интересуется фактами, приведу пример кода на нефункциональном языке Nice K>>
K>><T, U, V> T->U->V curry((T,U)->V func) = T parm1 => U parm2 => func(parm1, parm2);
K>>void main(String[] args) = println(curry((int a, int b) => a + b)(2)(2));
K>>
D>А вывести тип int умеет?
Насколько я знаю, типы аргументов в функциях в Nice нужно указывать явно. Так же, как и в туплах.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
<T, U, V> T->U->V curry((T,U)->V func) = T parm1 => U parm2 => func(parm1, parm2);
void main(String[] args) = println(curry((int a, int b) => a + b)(2)(2));
D>А вывести тип int умеет?
Не умеет, но это только мое мнение. Дело в том, что я по Nice, мягко говоря, не специалист, а компилятор не блещет умом и сообразительностью рапортуя об ошибках. Сначала я написал без int, но получив такой вот рапорт
Здравствуйте, eao197, Вы писали:
E>А как же немутабельные объекты? E>А как же все возвращает значение?
См. выше.
E>А пример, приведенный вашему, можно и на D 2.0 изобразить, там уже замыкания есть.
И как это будет выглядеть?
E>Так что, D уже функциональным языком стал?
Ну значит стал — не вижу в этом ничего сенсационного. Было бы странно, если бы язык, разрабатываемый в 2000-х годах им не стал.
E>Да и сам автор не причисляет Nice к функциональным языкам.
Позиционирование имеет значение в данном случае? Если позиционировать грейпфрут как лимон с "человеческим лицом", означает ли это, что это уже не грейпфрут?
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>А как же немутабельные объекты? E>>А как же все возвращает значение?
K>См. выше.
Ну, если ко всему выше перечисленному добавить еще и отсутствие раскрутки хвостовой рекурсии в компиляторе Nice, то, боюсь, вы останетесь единственным, кто считает Nice функциональным языком.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Klapaucius, Вы писали:
E>>А пример, приведенный вашему, можно и на D 2.0 изобразить, там уже замыкания есть.
K>И как это будет выглядеть?
Чуть-чуть пострашнее, но ведь исходному определению функционального языка это же не мешат, не так ли?
import std.stdio;
V delegate(U) delegate(T) curry(T, U, V)( V delegate(T, U) func )
{
V delegate(U) intermediateResult( T a )
{
V finalResult( U b )
{
return func( a, b );
}
return &finalResult;
}
return &intermediateResult;
}
void main()
{
int x = curry( delegate int( int a, int b ) { return a + b; } )( 3 )( 2 );
writefln( "x=", x );
}
// vim:ts=2:sts=2:sw=2:expandtab
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну, если ко всему выше перечисленному добавить еще и отсутствие раскрутки хвостовой рекурсии в компиляторе Nice, то...
Если вы все-таки желаете углубиться в терминологический спор, то приведите ваше определение функционального языка. Я свое определение привел и Nice полностью соответствует этому определению. То что предлагаете вы это простое перечисление совершенно несвязанных фич, и совершенно непонятно где оно должно начаться, а где закончится. Кто принимает решение входят ли в этот набор list comprehensions или классы типов? С таким же успехом можно утверждать что Java не является объектно ориентированным языком потому, что в ней нет мультиметодов, трейтсов и абстрактных интерфейсов a la тот же Nice. Безусловно, пищу для безудержного флейма на сто мореходных верст мелкими буквами такой подход дает, но я человек недостаточно прилежный или усидчивый чтобы принимать в нем участие заметное время.
Возражение о раскрутке хвостовой рекурсии, с моей точки зрения, не имеет отношения к функциональности, но имеет отношение к декларативности. Для языка без присваивания и, следовательно, циклов — раскрутка хвостовой рекурсии необходима для того, чтобы язык был тьюринг-полным, но для императивного языка это просто оптимизация, которой может и не быть. По моему мнению, функциональность — это метод декомпозиции, а императивность-декларативность — это гм... вычислительная модель. Они полностью ортогональны, с моей точки зрения. Если присоединиться к пуристам, считающим что функциональный язык должен быть декларативным, т.е. чистым и ленивым, то окажется что функциональных языков, по большому счету два — Haskell и Clean. Но если вы разделяете именно эту точку зрения — совершенно непонятно, почему вы считаете функциональным языком Scala. Короче говоря, ваша позиция по этому вопросу мне не ясна.
E>боюсь, вы останетесь единственным, кто считает Nice функциональным языком.
Не нужно бояться. В то время, когда вы написали это сообщение мое мнение о том, какой язык считается функциональным поддержал по крайней мере один пользователь форума помимо меня.
Продолжать эту ветку не обещаю, не сочтите за неуважение — просто продолжительное участие в терминологическом споре в мои планы не входит. Прочитав о том, что Nice де язык не функциональный, я просто продемонстрировал некоторые факты, которые могут показаться читателю форумов более полезными чем простое препирательство нет-да-нет-да-нет-да. Ознакомившись с приведенным мной кодом каждый может сам сделать для себя вывод по этому вопросу. Имеющий глаза да увидит.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Короче говоря, ваша позиция по этому вопросу мне не ясна.
Кажется, Страуструп сказал, что язык программирования поддерживает какую-то парадигму (да не обидится на меня Гена Васильев) только если язык поддерживает необходимые средства для использования этой парадигмы при программировании на этом языке. Например, поэтому язык C не считается ООЯ, хотя он и позволяет писать программы в стиле ООП. Поскольку по сравнению с ООЯ в C нужно прикладывать слишком много усилий для поддержки ООП.
Точно так же я смотрю и на функциональное программирование. Ключевым моментом в котором для меня является неизменяемость данных. Данные не изменяются и это делает возможным такие замечательные вещи, как прозрачный параллелизм без лишних синхронизаций, упрощенное тестирование, возможность при отладке возвращаться на произвольное число шагов (однако, лучше заглянуть сюда
Но для того, чтобы поддерживать иммутабельность данных, язык должен предоставлять разработчику ряд специальных средств. Среди которых нужно выделить такие, как:
хвостовая рекурсия, которая позволяет выражать циклы без использования переменных цикла. Например, вот так:
void
readLines( boolean showGoodMessages )
{
let stdin = new BufferedReader( new InputStreamReader( System.in ) );
void readAndProcessLine( String line )
{
if( line != null )
{
parseLine( line, showGoodMessages );
readAndProcessLine( readLine( stdin ) );
}
}
readAndProcessLine( readLine( stdin ) );
}
вместо императивного:
void
readLines( boolean showGoodMessages )
{
let stdin = new BufferedReader( new InputStreamReader( System.in ) );
var line = readLine( stdin );
while( line != null )
{
parseLine( line, showGoodMessages );
line = readLine( stdin );
}
}
иммутабельность данных, которая запрещает не только назначать переменным новые значения, но и запрещает изменять атрибуты уже собственных значений. Например, в OCaml для этого есть специальная синтаксическая конструкция, которая указывает при обращении к методу объекта создавать копию объекта с модифицированным значением:
class point =
object
val pos = 0
method get = pos
method set pos’ = {< pos = pos’ >}
end;;
Отдельно стоит сказать еще и о паттерн-матчинге. На мой взгляд, это не обязательная фича для функциональных языков. Но, поскольку в функциональном подходе для поддержки иммутабельности данных и отсутствия побочных эффектов широко применяется возврат значений в виде разнообразных туплов, то паттерн-матчинг является черезвычайно удобным механизмом для работы в таком стиле. Ярким примером из Scala является тип Some, работа с котором строится через паттерн-матчинг.
В отсутствии всего вышеперечисленного программирование на Nice в функциональном стиле, наверное, возможно. Но, как и с ООП в языке C, это будет слишком трудоемко по сравнению с действительно функциональными языками.
Не думаю, что я удовлетворил вашу потребность в определении функционального языка. Но надеюсь, что я объяснил причины, по которым я не причисляю Nice к функциональным языкам.
E>>боюсь, вы останетесь единственным, кто считает Nice функциональным языком.
K>Не нужно бояться. В то время, когда вы написали это сообщение мое мнение о том, какой язык считается функциональным поддержал по крайней мере один пользователь форума помимо меня.
Недостатком вашего определения является его поверхностность. Под него, по большому счету, не только D, но и C попадает. Т.к. в C указателями на функции можно манипулировать так же, как и экземплярами любых других данных.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>хвостовая рекурсия, которая позволяет выражать циклы без использования переменных цикла.
Ну, надо сказать, чтобы с помощью ФЯ выразить подобие цикла в ИЯ, можно использовать рекурсию вообще. То, что некоторые языки оптимизируют хвостовую рекурсию, разворачивая её в цикл — это лишь детали реализации. С таким же успехом я могу сказать, что если оптимизатор не умеет делать линеаризации при необходимости (это, например, вынуждает вручную делать рекурсию концевой при вычислении факториала), то язык не является функциональным. Кроме того, разворачивание концевой рекурсии имеет сомнительную полезность в случае, если язык имеет ленивую семантику, и компилится во что-то вроде g-машины или категориальной машины (собственно, я вообще не представляю как это сделать в данном случае).
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>хвостовая рекурсия, которая позволяет выражать циклы без использования переменных цикла.
K>Ну, надо сказать, чтобы с помощью ФЯ выразить подобие цикла в ИЯ, можно использовать рекурсию вообще.
И эта попытка завершается выходом за пределы стека при большом количестве итераций. Я привел примеры из программы на языке Nice для обработки текстовых файлов большого объема. Вариант с рекурсией ломался где-то после 3000-ысячной строки, а требовалось обрабатывать миллионы строк.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>хвостовая рекурсия, которая позволяет выражать циклы без использования переменных цикла.
K>Ну, надо сказать, чтобы с помощью ФЯ выразить подобие цикла в ИЯ, можно использовать рекурсию вообще. То, что некоторые языки оптимизируют хвостовую рекурсию, разворачивая её в цикл — это лишь детали реализации. С таким же успехом я могу сказать, что если оптимизатор не умеет делать линеаризации при необходимости (это, например, вынуждает вручную делать рекурсию концевой при вычислении факториала), то язык не является функциональным. Кроме того, разворачивание концевой рекурсии имеет сомнительную полезность в случае, если язык имеет ленивую семантику, и компилится во что-то вроде g-машины или категориальной машины (собственно, я вообще не представляю как это сделать в данном случае).
В G-машине, как я понимаю, это так и будет в виде циклического thunk'а храниться — будет немножко больше косвенности при обращении к аргументам (разыменование указателей). Но это — небольшая плата за приспособление к фон-неймановской архитектуре
Здравствуйте, eao197, Вы писали:
E>И эта попытка завершается выходом за пределы стека при большом количестве итераций. Я привел примеры из программы на языке Nice для обработки текстовых файлов большого объема. Вариант с рекурсией ломался где-то после 3000-ысячной строки, а требовалось обрабатывать миллионы строк.
Это проблема конкретной реализации. Никто не мешал сделать компилятор с данной оптимизацией, либо юзать велосипедный стек, который этого не боится. Но это никак не относится к тому, что язык является функциональным или нет.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>И эта попытка завершается выходом за пределы стека при большом количестве итераций. Я привел примеры из программы на языке Nice для обработки текстовых файлов большого объема. Вариант с рекурсией ломался где-то после 3000-ысячной строки, а требовалось обрабатывать миллионы строк.
K>Это проблема конкретной реализации.
Есть единственная реализация языка в виде единственного компилятора. Отсутствие хвостовой рекурсии в этой реалиции оставляет возможность только абстрактных разговоров о поддержке этим языком функционального стиля программирования.
K>Никто не мешал сделать компилятор с данной оптимизацией, либо юзать велосипедный стек, который этого не боится. Но это никак не относится к тому, что язык является функциональным или нет.
Я вот не понимаю. Допустим, язык Scala поддерживает хвостовую рекурсию. Может ли существовать компилятор Scala, не поддерживающий эту оптимизацию?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
K>>Это проблема конкретной реализации.
E>Есть единственная реализация языка в виде единственного компилятора. Отсутствие хвостовой рекурсии в этой реалиции оставляет возможность только абстрактных разговоров о поддержке этим языком функционального стиля программирования.
Не проблема написать реализацию, которая поддерживает данную оптимизацию. Семантика языка никак в этом не ограничивает.
K>>Никто не мешал сделать компилятор с данной оптимизацией, либо юзать велосипедный стек, который этого не боится. Но это никак не относится к тому, что язык является функциональным или нет.
E>Я вот не понимаю. Допустим, язык Scala поддерживает хвостовую рекурсию. Может ли существовать компилятор Scala, не поддерживающий эту оптимизацию?
Язык Scala поддерживает общую рекурсию. Другое дело, что имеющийся в наличии компилятор умеет разворачивать хвостовую рекурсию в цикл. Вполне возможно создать компилятор, который не поддерживает данную оптимизацию. Более того, если завтра появится компьютер, процессор которого умеет непосредственно редуцировать лямбда-выражения или комбинаторы, то подобная оптимизация вообще не понадобится.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, eao197, Вы писали:
K>>>Это проблема конкретной реализации.
E>>Есть единственная реализация языка в виде единственного компилятора. Отсутствие хвостовой рекурсии в этой реалиции оставляет возможность только абстрактных разговоров о поддержке этим языком функционального стиля программирования.
K>Не проблема написать реализацию, которая поддерживает данную оптимизацию. Семантика языка никак в этом не ограничивает.
Еще раз повторюсь, в отсутствии такой реализации все эти разговоры являются обсуждением сферического коня в вакууме.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
