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

>>> Типизация даже более строгая - полностью запрещены неявные приведения типов

Это где это в примере ProcessListOfPairs myList \x y -> x + y типы явно указаны?

Сначала типы похерили, а потом издеваются над декларацией типов в Паскале, которая для отлавливания ошибок смешения типов переменных придумана. Написали её один раз, декларировали все типы, чтоб не как в Бейсике ляпы и вызывай её родимую в одну строчку.

В большинстве статически типизированных ФЯ используется система типов Хиндли-Милнера, которая позволяет транслятору автоматически выводить наиболее общий тип функции, учитывая операции и функции, в ней задействованные. Это позволяет в большинстве случаев не указывать явно типы аргументов и результатов функций при полном сохранении жёсткой статической типизации. В некоторых случаях, правда, транслятор не в состоянии вывести нужный тип, ну так ничто не мешает всегда и везде указывать типы явно...
А иногда бывает и наоборот - укажешь явно тип функции - и бах! Он оказался черезчур обобщённым или наоборот, слишком конкретным! И транслятор отказывается принимать казалось бы корректный код. Убираешь строчку с указанным типом - и вуаля - всё прекрасно компилируется и работает! :о))

Хорошо x+y вписывать в качестве параметров.
А если функция длинная? Или такие задачки на решаем? Или Лучше анонимно весь листинг в параметры каждый раз копипэйстировать?

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

Ответ на »сообщение 5175« (Руслан Богатырев)
___________________________

>>>Собственно, такое убеждение у меня сложилось при знакомстве с языком Modula-3 в начале 1990-х годов, где по сути этот подход и реализован. Думаю, в новом языке (усл. название Norebo-1), который будет создаваться в рамках проекта "Роса", именно так и будет реализован цикл FOR.

А что стало с языком Модула-3?
Создается впечатление, что это очень хороший, качественный язык.
Почему он все-таки не прижился?

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

Ответ на »сообщение 5291« (Geniepro)
___________________________
Типизация даже более строгая - полностью запрещены неявные приведения типов
Это где это в примере ProcessListOfPairs myList \x y -> x + y типы явно указаны?

Не нужно путать теплое с мягким. Строгая типизация не обязана быть явной. Более того, она не обязана быть даже статической.

Сначала типы похерили, а потом издеваются над декларацией типов в Паскале, которая для отлавливания ошибок смешения типов переменных придумана. Написали её один раз, декларировали все типы, чтоб не как в Бейсике ляпы и вызывай её родимую в одну строчку.

Некоторые вариации на тему вывода типов позволяют выявлять кое-какие ошибки, которые при помощи явной типизации выловить, наверное, тоже можно, но только писанины будет куда больше (настолько больше, что с вероятностью повыше 0.9 писать все требуемые декларации не будут). Впрочем, это пока лишь исследовательские работы.

Еще автоматический вывод типов хорошо сочетается с метапрограммированием.

Хорошо x+y вписывать в качестве параметров.
А если функция длинная? Или такие задачки на решаем? Или Лучше анонимно весь листинг в параметры каждый раз копипэйстировать?


Из моей практики, чаще всего требуются как раз такие вот функции на две-три операции, но с "полезной нагрузкой" в виде замыкания по некоторым свободным переменным. Если писать однострочники кажется не слишком наглядно, никто не запрещает определить локальную функцию (лисповский flet или let/where в Haskell). Кстати, функцию эту можно будет не только передавать как параметр "вглубь", но и вернуть в составе результата "наружу", в отличие от ...

Ответ на »сообщение 5291« (Geniepro)
___________________________
Типизация даже более строгая - полностью запрещены неявные приведения типов
Это где это в примере ProcessListOfPairs myList \x y -> x + y типы явно указаны?

Сначала типы похерили, а потом издеваются над декларацией типов в Паскале, которая для отлавливания ошибок смешения типов переменных придумана. Написали её один раз, декларировали все типы, чтоб не как в Бейсике ляпы и вызывай её родимую в одну строчку.
Хорошо x+y вписывать в качестве параметров.
А если функция длинная? Или такие задачки на решаем? Или Лучше анонимно весь листинг в параметры каждый раз копипэйстировать?

Ответ на »сообщение 5290« (Руслан Богатырев)
___________________________

Если Вас интересует мое мнение, то Лисп менее пригоден, чем Оберон для задач системного программирования на существующей массовой процессорной архитектуре Intel/AMD. Допускаю, что у Вас -- несколько иное мнение.

1. Подмена понятий. Если мне не изменяет память, »сообщение 5231« касалось архитектуры фон-Неймана в целом.

2. Мнения, не подтвержденные фактами, в технической дискуссии стоят недорого.

Ответ на »сообщение 5257« (Руслан Богатырев)
___________________________

Боюсь, пока в ФП не придут оберонщики с самыми серьезными намерениями, ФП так и будет буксовать... :)

Меня эта тема заинтересовала, и начал я думать, что же современные оберонщики могут дать современным функциональщикам? ;о)

• Модульность? Модули в том или ином виде давно уже присутствуют в функциональных языках. И если в Хаскелле модули примерно похожи на Обероновские (за исключением того, что для Хаскелла вроде нет фреймворков, похожих на Блэкбокс, в которых можно динамически загружать-выгружать модули), то Лисп и Эрланг идут даже дальше - там можно динамически, во время работы программы заменять функции, без остановки самой программы! Оберонам до этого ещё далеко, а в лиспах это было ещё десятки лет назад...
  
  
• Герметичная система типов? Так в статически типизированных ФЯ системы типов ничуть не менее герметичны, чем в Оберонах... Типизация даже более строгая - полностью запрещены неявные приведения типов, в отличие от Оберонов, в которых INTEGER - подтип LONGINT'а, который в свою очередь - подтип REAL'а, который опять же подтип LONGREAL'а... Хаскелл или Окамл в этом плане более безопасны, чем Обероны...
  
  
• Активные асинхронные объекты? В лиспах это было ещё когда был моден Смоллток со своими асинхронными активностями. Эрланговские или хаскеллевские потоки тоже похожи на такие объекты... Ну разве что никто пока не додумался прикрутить DSL, который будет описывать протоколы взаимодействия объектов аля Зоннон/Композита...
  
  
• Generic Message Bus? Имея удобные средства посылки сообщений по каналам связи, можно легко обойтись без или при желании сэмулировать эту самую шину сообщений. В чём тут какая-то особенная фишка?
  
  
• Метапрограммирование с использованием RTTI? Так в хаскеллах-окамлах такая метаинформация тоже есть. Более того, средства метапрограммирования в Template Haskell, MetaML и особенно в Лиспах и Немерле куда более мощные и удобные, чем в Оберонах! Тут оберонщикам опыт перенимать надо...
  
  
• Расширяемые записи? Оберонщики используют своё "метапрограммирование" в основном что бы создавать полиморфные процедуры и типы, вместо того, что бы явно ввести полимофизм в систему типов. Точнее, в Оберонах есть некоторые виды полиморфизма - полиморфизм включения (расширение типов записей), перегрузочный полиморфизм (Oberon Companion, Zonnon) и полиморфизм "приведенческий" (coercion) - вспомните совместимость разных числовых типов. А вот самого удобного полиморфизма - параметрического - нету! Как так? А вот в том же Хаскелле есть и параметрический, и перегрузочный - самые полезные - виды полиморфизма!
  
  Собственно, расширяемые записи тоже имеются в Окамле, есть диалекты Хаскелла с этой фишкой (O'Haskell, например), только вот хаскеллеры что-то не оценили эту традиционную ООП-возможность... Так что полиморфизм включения не особенно полезен для ФП. А приведения типов (четвёртый вид полиморфизма) - просто опасен и не нужен!
  
  И если уж речь зашла о поддержке ООП в функциональных языках, то CLOS в лиспе - пожалуй самая мощная система ООП на сегодня!
  
  
• Может быть, оберонщики смогут придумать новый функциональный язык, который будет следовать традициям Вирта? Это должен получиться простой компактный язык с минимумом средств и элегантным синтаксисом. Давайте представим его себе!
  
  Учитывая пристрастие оберонщиков к статической типизации и паническую боязнь новых веяний в системах типов, по семантике этот язык будет похож на CAML Light, видимо. Никаких классов типов, элегантно решающих проблему перегрузочного полиморфизма, не будет, как не будет и всяких экзистенциальных типов... Скорее всего, не будет и отложенных вычислений в этом языке...
  Синтаксис - в лучшем случае хаскеллевский, ФЯ с обероновским синтаксисом - это будет страшно!
  
  Так сможет ли этот гипотетический упрощённый ФЯ заинтересовать современных функциональщиков, избалованных такими вещами, как sexy types и макросы? Очень сомнительно...
  Хотя реализация этого языка могжет быть весьма эффективной - не хуже чем у Окамла. Но ведь уже и так есть Окамл...
  
  
• Эффективная, надёжная и перенсимая реализация рантайма для ФЯ? Да, тут Оберон был бы неплох, хотя конкурировать с Си в этом плане оберонам будет очень и очень нелегко!
  И ещё, почему тут такая буча возникла по поводу анонимных функций? Я упомянул, что такие функции, а точнее, closures, удобно реализуемые с их помощью, могли бы очень сильно помочь при реализации рантайма для ленивых ФЯ типа Хаскелла. Без closures, которых, увы, нет в Оберонах (как, впрочем, и в Си), придётся делать либо сложную систему отложенных вычислений, либо простую, но тормозную...
  
  Теперь я понимаю, почему ленивую виртуальную машину LVM (Lazy Virtual Machine) реализовали на Окамле, а не на Си или Обероне - на ФЯ это гораздо легче сделать. И получилось ненамного менее эффективно, чем было бы на Си, и ничуть не менее надёжно, чем на Обероне!
  

ЗЫ. Буду рад, если окажется что я в чём-то тут ощибся, и мне укажут, чем же именно оберонщики могут так сильно помочь функциональщикам, что даст ФП новый толчок развития... А то действительно, такие фундаментальные сдвиги в ФП, как система типов Хиндли-Милнера, классы типов, монадный ввод-вывод, стрелки потоков управления, распараллеливание на уровне данных и прочее довольно редко случается...

Ответ на »сообщение 5276« (Lisp Hobbyist)
___________________________

Правильно ли я понимаю, что кроме этих правдоподобных рассуждений, у Вас нет конкретных технических аргументов, подтверждающих непригодность Лиспа для императивного (в т.ч. низкоуровневого) программирования?

Если Вас интересует мое мнение, то Лисп менее пригоден, чем Оберон для задач системного программирования на существующей массовой процессорной архитектуре Intel/AMD. Допускаю, что у Вас -- несколько иное мнение.

Ответ на »сообщение 5288« (Geniepro)
___________________________
Так вопрос фактически ставился о том, можно ли обойтись без поименованных функций, только с одними анонимными?
Че то я упустил этот момент. Где это вопрос так ставился ?
Анонимные функции конечно отличная вешь. Но их область применения - это одноразовые функции.
Любая функция, имеющая пользу в общем смысле а не только в одной конкретной ситуации, уже должна быть именована. Поэтому я не понимаю как можно ставить вопрос о программировании только с помошью анонимных функций ? Это что, такой экстремальный спорт ?

Ответ на »сообщение 5286« (Jack Of Shadows)
___________________________

Ну это непрактичное решение. Легче все таки просто поименовать функцию чем так извращаться.

Так вопрос фактически ставился о том, можно ли обойтись без поименованных функций, только с одними анонимными? Вспомнив о том, что есть четыре известных фундаментальных теории вычислений (лямбда вычисление, машина Тьюринга, нормальные алгорифмы Маркова и комбинаторная логика), приходим к выводу, что вполне можно! ;о)

И ещё, какие там извращения? Ну подумаешь, использовать одну дополнительную функция (стандартный Y-комбинатор), да имя вашей функцию превратить в дополнительный параметр анонимной функции - всего и делов-то! :о))

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

А это посложнее, у НОДа два параметра, а не один, как у факториала...

На самом деле, ничего сложного:

gcd m n = if n == 0 then m else gcd n (m `mod` n)

лёгким движением руки переписываем в анонимную функцию:

(y (\f m n -> if n == 0 then m else f n (m `mod` n)))

Проверяем:

y f = f (y f)

main = do
    print $ (y (\f m n -> if n == 0 then m else f n (m `mod` n))) 121 110

11

Всем срочно смотреть слайды техасского доктора "Recursive Definitions, Fixed Points and the Y  Combinator" by Dr. Greg Lavender