Помогите господа маститые программеры

>про это оч хорошо написано в сатье

Не вижу я ничего хорошего. Чтобы хорошо разбираться в ФП, нужно хорошо знать дискретную математику, это все-таки первично. Притом я еще ни разу не видел книгу, которая бы покрывала весь объем необходимого материала. Только учиться, либо на матфаке, либо там, где читают адекватные курсы ФП.

ФП программы хорошо распараллеливаются чисто теоретически. Чисто на практике, программе приходится взаимодействовать с окружающим миром. Совсем одно написать параллельную программу, которая будет считать факториал/Фибоначчи, и совсем-совсем другое дело программу, которая будет, допустим, параллельно парсить файл.

Более того, обычно еще требуется виртуальная машина со своим собственным планировщиком (хаскель, эрланг).

> А второе твое счастливое число 14? :D

А почему тебя это так беспокоит?

Назвать Вадлера "тупоголовым фанатиком" - это надо быть уж совсем неграмотным и дремучим. Гуляй мимо.

>Разница такая, что с метапрограммированием никакого кодогенератора писать не надо вообще, оно само получится, бесплатно

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

если же у нас eDSL, то какие у тебя претензии, например, к Parsec? к Reactive? они полностью на комбинаторах, никакого метапрограммирования. а если оно таки нужно, то вот тебе примеры:

http://www.eecs.harvard.edu/~mainland/ghc-quasiquoting/

там ссылка на статью, в которой в качестве eDSL в Haskell зашивается ассемблер и TinyC

ещё к вопросу о eDSL в Haskell:

http://zelych.livejournal.com/9922.html?thread=18370#t18370

это про Harpy, если что. кстати, есть аналоги для CL?

>ФП программы хорошо распараллеливаются чисто теоретически

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

а во-вторых не только (и не столько) в параллелизации приятность ФП

> так. давай определимся - у нас DSL или eDSL?

Не важно, на самом деле.

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

Ну, если заморачиваться над эфемерной разницей между подходами Happy и Parsec - то как-то так. Но кого это волнует?

> если же у нас eDSL, то какие у тебя претензии, например, к Parsec?

Тормоз он. Сравни со встраиваемыми в Common Lisp компилирующими реализациями, нупример, того же Packrat.

> они полностью на комбинаторах, никакого метапрограммирования.

И потому тормоза. Для некоторых простых задач этого достаточно, но в общем случае ни фига не работает. Следай на комбинаторах тот же аналог LINQ, с полноценной раскруткой вложенных map-ов (про rewrite rules знаю - это очень частное решение, не годится в этой задаче).

> а если оно таки нужно, то вот тебе примеры: Я про TH выше уже писал - это ровно тот же подход, что и в Lisp, то есть, по твоей классификации - AST головного мозга. И к TH у меня множество претензий - полноценного лиспа он не заменяет, хотя бы по той причине, что синтаксис макроподстановки отличается от синтаксиса всех прочих конструкций, и по причине невозможности изменить синтаксис внутри самой макры - она работает с тем же AST, что и Haskell.

> это про Harpy, если что. кстати, есть аналоги для CL?

Полно, во многих реализациях Лиспа есть встраиваемый ассемблер.

>ну во-первых не так всё страшно. то есть да, чудес там нет,- но в императивных языках (за исключением erlang - ну да он вообще специфичен) это делается всё же существенно сложнее

В erlang тоже нет автоматической векторизации. А в ghc 6.10 есть -fvectorize - правда пока сильно сырое - но работы ведутся.

Насчет DSL:

для eDSL - комбинаторы и Teamplate Haskell

для DSL - BNF converter.

>> А второе твое счастливое число 14? :D

> А почему тебя это так беспокоит?

Меня это не беспокоит. Просто провожу социологическое исследование о связи Лиспа с фошызмом.

>Тормоз он. Сравни со встраиваемыми в Common Lisp компилирующими реализациями, нупример, того же Packrat.

Да он медленный, но если его гонять на стадии компиляции через Template Haskell то кого это волнует?

А так можешь сравнить по скорости с BNF converter / Happy - они заметно быстрее.

>И потому тормоза. Для некоторых простых задач этого достаточно, но в общем случае ни фига не работает. Следай на комбинаторах тот же аналог LINQ, с полноценной раскруткой вложенных map-ов (про rewrite rules знаю - это очень частное решение, не годится в этой задаче).

Чем это rewrite rules не угодили интересно?

> Да он медленный, но если его гонять на стадии компиляции через Template Haskell то кого это волнует?

Мы и сравниваем метапрограммирование, то есть, генерацию кода во время компиляции, AST головного мозга, с "кошерными" комбинаторами.

> Чем это rewrite rules не угодили интересно?

Тем, что далеко не на все случаи шаблон нарисовать можно, тогда как foreach/yield в C# компилируется корректно всегда.

>Ну, если заморачиваться над эфемерной разницей между подходами Happy и Parsec - то как-то так. Но кого это волнует?

хм? подход Parsec по ряду причин намного удобней. по ним же - существенно тормозней. ты об этом?

>Тормоз он. Сравни со встраиваемыми в Common Lisp компилирующими реализациями, нупример, того же Packrat

сравню

>Для некоторых простых задач этого достаточно, но в общем случае ни фига не работает

в общем случае вообще как правило VB.Net используют

>Я про TH выше уже писал

это не TH. вернее, не только TH

>Просто провожу социологическое исследование о связи Лиспа с фошызмом

следующий этап - оценка связи с пузи-сотонизмом и проверка подёргивания конечностей при прослушивании 51k?

> хм? подход Parsec по ряду причин намного удобней. по ним же - существенно тормозней. ты об этом?

Ну, если с Happy (и прочими [E/L]BNF) сравнивать - то удобнее. Если с PEG - то уже ни фига подобного. Так что никакой связи между удобством и тормозами нет. На метапрограммировании можно делать и удобно и быстро одновременно.

>Мы и сравниваем метапрограммирование, то есть, генерацию кода во время компиляции, AST головного мозга, с "кошерными" комбинаторами.

Одно другому не мешает. Комбинаторы полезны и сами по себе. Для большинства задач разница в скорости совершенно не принципиальна.

>Тем, что далеко не на все случаи шаблон нарисовать можно, тогда как foreach/yield в C# компилируется корректно всегда.

list fusion тоже всегда работает как ни странно.

> социологическое исследование о связи Лиспа с фошызмом.

поделишься предварительными результатами?

>а во-вторых не только (и не столько) в параллелизации приятность ФП

Очень часто приятность функциональных языков заключается в вещах, не имеющих к фп никакого отношения.

> http://kmmbvnr.livejournal.com/62197.html

Сие по-моему есть отчаянное ковыряние в комариных жопках. Мне как стороннему наблюдателю принципиального качественного положительного отличия между схемой и хаскелем (мирандой) для задачи обучения студентишек не видно.

>Тормоз он. Сравни...

Кстати, я не стал бы обсуждать на _таком_ уровне. "Тормознутось" - понятие очень относительное.

Кроме того, как мне кажется, мы движемся назад в будущее: помнится в середине 90-х были распространены серваки с десятков pentium'ов, плюс еще десяток 486-х для как процессоры ввода-вывода.

Хочу напомнить, что с параллельностью в CL дела вообще никак не обстоят: отдано на откуп реализаторам. И то что сейчас тормозит в хаскеле через некоторое время может и обгонять лисп.

>принципиального качественного положительного отличия

щито?

>Очень часто приятность функциональных языков заключается в вещах, не имеющих к фп никакого отношения

ну так тем более же!