Ответ на »сообщение 2391« (Geniepro)
___________________________

Ответ на »сообщение 2384« (Руслан Богатырев)
___________________________
Неужели Вы действительно думаете, что решать типичные школьные задачки на Обероне легче, проще и быстрее, чем на этих трёх языках?

Знаете, я как-то не помню никаких проблем с решением "типичных школьных задачек" на Паскале, когда был в школе... В 11 классе реализовывал даже распознавание образов на Дельфе - и вполне успешно (программа заняла 1 место на всеройссийском конкурсе Intel-Авангард).
Так вот, о чем я - освоить паскалеский инструмент школьнику вполне по силам самостоятельно, как по силам и делать на нем что-то реальное. А если говорить о ББ - то вообще, более или менее способный школьник унесет с собой не только основы алгоритмизации, но и отличный "карманный" инструмент для решения каких-либо несложных задачек или "любительского" программирования в дальнейшем.
А вот с ФП-то, господа, вы как раз ставите школьнику жесткий "потолок": вроде бы и все легко сначала, и функции вы рекурсивные попишете, но дальше для самостоятельной работы дорога закрыта - для окончившего школу и не ставшего проф. программистом два выбора: либо так ничего никогда и не написать за пределами школьного курса, либо лезть в дебри сверхвысоких для среднего ума абстракций...

Если сформулировать предварительное впечатление от обсуждения, то функциональщики несколько увлекаются деталями языка Хаскель, как будто ФП и Хаскель одно и то же (на мой взгляд, Хаскель -- частный случай), а оберонщики склонны не замечать механизмы, отсутствующие в "чисто" императивных языках (например -- лямбды; каюсь).

Ответ на »сообщение 2395« (AVC)
___________________________

Ответ на »сообщение 2393« (Geniepro)
___________________________

Просто потому, что это главная единица лямбда-исчисления - основы ФП.
По-моему, не существует ни одного ФЯ, в котором бы не было лямбд.

Насколько я понял, необходимости в лямбдах нет, как и прямой связи между лямбдами (как безымянными функциями) и функциональностью (в смысле ФП).

Я подумал и решил, что вчера был неправ. :)
Действительно, λ нужна для анонимного и динамического создания функций.
Это как раз та специфика ФП, которая выходит за рамки отсутствия побочных эффектов и относится к функциям как "объектам первого порядка".
Короче, возражение по этому пункту снимаю.

Ответ на »сообщение 2398« (slava)
___________________________
Синтаксический сахар, как анонимные классы в Java.
Верно. Однако 2 замечания.
Во первых анонимные классы в java - это провальный эксперимент. Слишком громоздкий синтаксис. Синтаксический сахар должен быть коротким и удобным. Иначе его смысл теряется.

Во вторых в данном конкретном случае это смотря с какой стороны смотреть.
Со стороны ИЯ - анонимные функции это синтаксический сахар.
Со тороны ФЯ - наименование функций это синтаксический сахар, потому что лямюа является основополагающей абстрацией, основным механизмом, солью ФП

То есть функция в ФП записывается так:

f = lamdba x y -> bla bla x y

и привычное вам обьявление функций
f(x,y) = bla bla - это с точки зрения ФП и есть синтаксический сахар к лямбде.

Здесь (<10) является анонимной функцией. Не будь этой фозможности вам пришлось бы писать так:

Синтаксический сахар, как анонимные классы в Java.

Ответ на »сообщение 2396« (AVC)
___________________________
Я просто никак не могу себе хорошо представить эту глобальную структуру, в которой все хранится. :)

Попробуйте написать сами.

Короче, один пример (даже схематичный) стоит тысячи слов.
Вам уже этот пример приводили. В целых 63 строчки. Требовать от кого либо чтобы он тратил на вас свое свободное время, мягко говоря некорректно. Хотите посмотреть код побольше и посложнее - есть такие известные open source проекты на хаскеле как darcs, pugs, HaskellDB, и еще много много других библиотек.
Есть также и большие программы типа Quake на хаскеле. Тоже с исходным кодом.

Ну какая принципиальная разница, именована функция или нет, если ее имени не видно за пределами модуля?
Почему, собственно, без анонимных функций нет ФП?


Во первых динамическое создание функций. Там названия так просто не дашь.

Во вторых я уже приводил примеры как раз показывающие преимущество использования анонимных функций.
Приведу еще раз

less_than_10 = filter (< 10) mylist

Здесь (<10) является анонимной функцией. Не будь этой фозможности вам пришлось бы писать так:

is_less_than_10 x = x < 10
less_than_10 = filter is_less_than_10 mylist

Ответ на »сообщение 2394« (Geniepro)
___________________________

Ну так меняйте, в чём проблема-то?
Если этот тип - абстрактный, то вся работа с ним будет вестись через набор операций, с ним связанных, а кишки его будут спрятаны в каком-нибудь отдельном модуле. Сама структура-то собственно и не всплывёт наружу - это ведь абстрактный тип данных.

Я просто никак не могу себе хорошо представить эту глобальную структуру, в которой все хранится. :)
Как она соединяется в одно целое?
Как с ее помощью получить доступ к отдельным объектам?
И т.д.
Конечно, причиной может быть моя неопытность в ФП.
Мое представление о соединении структур данных в ФП ограничено использованием пар в Схеме (car, cdr etc).

Короче, один пример (даже схематичный) стоит тысячи слов.

Ответ на »сообщение 2393« (Geniepro)
___________________________

Просто потому, что это главная единица лямбда-исчисления - основы ФП.
По-моему, не существует ни одного ФЯ, в котором бы не было лямбд.

Насколько я понял, необходимости в лямбдах нет, как и прямой связи между лямбдами (как безымянными функциями) и функциональностью (в смысле ФП).
Начиная с Алгола-68, существуют императивные языки, ориентированные на ?-исчисление, но не ставшие от этого функциональными.


Разве Оберон (или др. ИЯ) обязан подражать ФП во всех деталях реализации?
Конечно же не должны, на то они и не функциональные языки.

Переформулирую. :)
Разве все ФЯ реализуют ФП одинаково?
Я просто хочу подчеркнуть, что Вы сводите разговор на уровень реализации (не ФП, а Хаскель; лямбды есть во всех ФЯ, а в Обероне нет и т.д.) вместо уровня концепций.


Вместо локальной процедуры вполне можно вернуть объект с функцией (функтор, объект-функцию).
Это уже ООП...

Разве?
Хочу напомнить, что в функторы (объекты-функции) в STL никакого отношения к ООП не имеют.
А то, если так рассуждать, то почти все ИЯ являются еще и ФЯ: ведь практически в каждом есть функции. :)


Языки, в которых функции не являются объектами первого класса, по определению не являются функциональными языками. Всё-таки главное в ФП - функции, всё остально вертится вокруг них, а не они вокруг всего остального.

Здесь у меня есть некоторое сомнение.
Ведь функция есть некое отображение.
Может ли она логически быть первой ("главной"), если само ее определение предполагает существование других объектов (не функций)?


Конечно же, аскеты не нуждаются в новомодных штучках, но зачем отказываться от удобств-то?

Так же говорили и сторонники PL/I. :)
"Мы слишком любили удобства."


Конечно, очень большого труда не составит, но труд будет всё-таки больше.
Это опять же из раздела автоматизации труда программиста. Сборщик мусора необязателен, но очень желателен. Так же и list comprehensions необязательны, но очень желательны...

Пардон?
Я правильно понял, что в ФП сборщик мусора -- необязательный элемент, кусок синтаксического сахара?
Например, в Обероне его необходимость считается математически доказанной...

>>>Э-э, это не ко мне. Не я постановщик этого вопроса ("Может ли Оберон использоваться как ФЯ?")

Повторю вопрос: все ФЯ реализуют ФП одинаково?


Между кортежами и записями есть небольшая разница. Кортежи можно рассматривать как безымянные записи. Т.е. при использовании записей приходится создавать специальные новые типы, при использовании кортежей от этой ненужной работы можно избавиться.

Кому ненужная работа, а кому спасение.
Илья Ермаков уже много раз говорил о том, какую роль играет т.н. "избыточность".
Не верите нам, так хотя бы возьмите в руки учебник по теории кодирования (раздел дискретной математики).

>>>Так и язык ведь он не функциональный, а императивный. Потому и по-другому устроен...

Вместе с тем, он позволяет писать в функциональном стиле.
Естественно, это не слишком удобно, но возможно (а речь и шла именно о принципе).

Ответ на »сообщение 2392« (AVC)
___________________________

Вот создал я АТД, а он должен торчать "кишками наружу", чтобы выдержать принципы ФП.
Допустим, от многих неприятностей меня функциональность как раз и защитит (не даст модифицировать мои структуры данных).
Но что будет, если мне потребуется изменить эти структуры?
В модульном и объектно-ориентированном программировании здесь нет никаких проблем (да-да, то самое сокрытие информации), но там структура данных не всплывает наверх, в отличие от ФП.

Ну так меняйте, в чём проблема-то?
Если этот тип - абстрактный, то вся работа с ним будет вестись через набор операций, с ним связанных, а кишки его будут спрятаны в каком-нибудь отдельном модуле. Сама структура-то собственно и не всплывёт наружу - это ведь абстрактный тип данных.
А если Вы вдруг поменяете интерфейс этого типа - то тут Вас не спасёт и ООП...
Если же "кишки наружу" будут, то какой же это АТД? :о))

Эти данные будут у Вас проходить через главный поток управления - но они же не будут размазаны по всей программе! Доступ к ним будет жёстко ограничен, а интерфейс - абстрактным! В чём проблема-то? Главный поток (называйте как хотите - монада ввода-вывода или как-нибудь по другому...), так вот, главный поток программы и будет тем самым модулем, который скрывает свои данные от чужих рук и глаз...

Ссылка в тему: D. Obradovic "Structuring functional programs by using monads"

Ответ на »сообщение 2390« (AVC)
___________________________

Лямбда-абстракции (безымянные/анонимные функции) - это очень важный элемент ФП, который напрочь отсутствует в Оберонах. Без этого элемента язык не может считаться функциональным.

Почему?

Просто потому, что это главная единица лямбда-исчисления - основы ФП.
По-моему, не существует ни одного ФЯ, в котором бы не было лямбд.

Главное отличие поименованных функций от безымянных в том, что безымянные создаются динамически, а поименованные - статически.


Разве Оберон (или др. ИЯ) обязан подражать ФП во всех деталях реализации?

Конечно же не должны, на то они и не функциональные языки.

Вместо локальной процедуры вполне можно вернуть объект с функцией (функтор, объект-функцию).

Это уже ООП...

Языки, в которых функции не являются объектами первого класса, по определению не являются функциональными языками. Всё-таки главное в ФП - функции, всё остально вертится вокруг них, а не они вокруг всего остального.


Сопоставление по образцу (pattern matching) - очень модный аттрибут современных ФЯ и некоторых гибридных языков.

Причем здесь ФЯ?

Да ни при чём, просто это сейчас очень модно в ФЯ. Мода, ничего больше.
Конечно же, аскеты не нуждаются в новомодных штучках, но зачем отказываться от удобств-то?

Вообще, pattern matching - аттрибут декларативного программирования, а так как ФП часто относят к разделу ДП, то в ФЯ этот элемент очень желателен - повышает уровень декларативности программ.


Если содержимое массива можно задать в "удобной декларативной манере" (т.е. не надо перечислять все элементы, а есть некая система), то и в императивной большого труда не составит.
Это из области синтаксического сахара.

Конечно, очень большого труда не составит, но труд будет всё-таки больше.
Это опять же из раздела автоматизации труда программиста. Сборщик мусора необязателен, но очень желателен. Так же и list comprehensions необязательны, но очень желательны...


Опять же, предрассудок, что Оберон должен делать все так же, как ФЯ.

Э-э, это не ко мне. Не я постановщик этого вопроса ("Может ли Оберон использоваться как ФЯ?")

Между тем, кортежи в Обероне есть -- это записи-параметры.
На их использовании основана работа часто упоминаемой в обероновской ветке software bus.
Запись можно передать в качестве аргумента, можно вернуть в качестве результата.

Между кортежами и записями есть небольшая разница. Кортежи можно рассматривать как безымянные записи. Т.е. при использовании записей приходится создавать специальные новые типы, при использовании кортежей от этой ненужной работы можно избавиться.


Могу выделить два пункта.
1) Большая любовь к синтаксическому сахару (что для ФЯ, возможно, необходимость).

Синтаксический сахар не только приводит к раку точки с запятой, но иногда просто делает язык вкуснее... :о))

2) Уверенность, что Оберон должен реализовывать некую функциональность так же, как ФЯ. Поэтому просто выпадает из зрения тот факт, что он эту функциональность реализует по-другому.

Так и язык ведь он не функциональный, а императивный. Потому и по-другому устроен...