Функциональщина. Что выбрать?

>Если за двадцать лет так почти никому и не понадобилась статическая типизация в липе, то какой отсюда вывод напрашивается? что статическая типизация может быть полезна в очень узких областях, где нужно проверять только корректность

Ну я бы не называл области в которых есть проверка корректности узкими. Корректность нужна повсеместно. Хотя кроме типизации есть есчё куча наворотов, например XML схемы. Но тут уже встаёт вопрос эффективности и целесообразности.

> Както взялся за задачу конвертации XML в структуры данных описаные на Haskell или OCaml.

А CDuce пробовал?

>Если за двадцать лет так почти никому и не понадобились макросы в Хаскеле...

Эм, может они пока просто не додумались? Сейчас только шаблоны осиливают.

Если за двадцать лет так почти никому и не понадобились замыкания в C...

Это язык другого уровня.

>А CDuce пробовал?

Я подозревал что есть чтото готовое. Теперь можно не напрягать мозги по этому поводу, а занятся чемнибудь прикладным и полезным.

В общем, спасибо за наводку, я пошёл курить маны :)

Эм, может они пока просто не додумались?

Ну дык а про Лисп что?

> Ну дык а про Лисп что?

А что там? Там зачатки статической типизации, что-то более сложное сделать нельзя ибо очень многое завязано на рантайм. Soft typing есть, но им практически никто не пользуется.

Кстати, у меня есть несколько вопросов по TH. Буду благодарен за ответы.

1. можно ли там писать макросы, которые пишут макросы, или которые определяют типы и функции.

2. как решается проблема с захватом имен переменных.

Там зачатки статической типизации, что-то более сложное сделать нельзя ибо очень многое завязано на рантайм.

О чём и речь. Потому и «никому не понадобилось».

Кстати, у меня есть несколько вопросов по TH.

Я не особый спец по TH - посмотрел год или два назад, понял, что не нужно, и забил. Лучше спрашивать thesz-а в его ЖЖ, он довольно активно это дело пользует.

можно ли там писать макросы, которые пишут макросы, или которые определяют типы и функции.

В TH нет макросов, там только функции, работающие с AST. Одну и ту же функцию можно вызывать и в рантайме и при компиляции (правда, если она возвращает AST, то вызывать её в рантайме не очень осмысленно).

Определять типы можно, равно как и всё остальное - классы, инстансы и те де. Вроде бы, не поддерживается (пока) стрелочный синтаксис (proc); впрочем, информация могла и устареть.

как решается проблема с захватом имен переменных.

Есть функция, выдающая гарантированно уникальное имя. Как и в Лиспе.

Там зачатки статической типизации, что-то более сложное сделать нельзя ибо очень многое завязано на рантайм.

qi сделан, только не востребован. насколько это сложно, можно сравнить по строчкам кода. сам qi:

lisp:          7797 (99.97%)
sh:               2 (0.03%)

и, например, sbcl:

Totals grouped by language (dominant language first):
lisp:        330817 (91.43%)
ansic:        26146 (7.23%)
asm:           2486 (0.69%)
sh:            2395 (0.66%)

И это, кстати, основная проблема Qi.

А макросы в Хаскеле таки понадобились. Как и пластичность синтаксиса, которую пытаются заменить сахаром.

>1. можно ли там писать макросы, которые пишут макросы, или которые определяют типы и функции.

Я так понял тут надо s/макрос/шаблон/g , хотя тут замена оправдана, так как семантически хаскелевские шаблоны соответствуют лисповским макросам.

Все типы данных из TH взвимо-однозначно соответствуют синтаксическим конструкциям хаскеля. Подставить можно любую часть программы или даже программу полностью.

По этим типам я когдато даже составил DTD, рассматривая возможность удобного их редактирования в XML редакторах. А так же, рассматрвал возможность генерации кода из DSL на основе XML. В общем, всячески пытался извлеч выгоды и удобства.

В общем для типов данных типы данных TH имеются.

2. как решается проблема с захватом имен переменных.

Проблема решается написанием шаблонов, которые не захватывают имена переменных. Тоесть, тут я не вижу никаких проблем.

Есть проблема захвата имён типов и конструкторов, но тут можно попробовать сгенерировать отдельные модули. Хотя я так не делал и какой инструкцией это делается не помню.

>И это, кстати, основная проблема Qi.

Документация - проблема многих хороших вещей :(

PS

Ктонибудь пропустите это через распознавалку, это реально нечитабельно!

Присоединяюсь к просьбе

>>Эм, может они пока просто не додумались?

Да не нужен этот костыль в достаточно развитых функциональных языках. У TH основное использование на хакадже - генерация instance'ов. В принципе, такое проще писать через class Data, просто instance (Data a) => Smth a where породит слишком много лишних инстансов, на то, где они нафиг не нужны, а идиоты дефолтную имплементацию через Data.Data.Data писать стесняются. больше его использовать практически не за чем.

А макросы в Хаскеле таки понадобились.

А я сказал «почти никому». Я вот, например, пока пользы от них не увидел.

> Ктонибудь пропустите это через распознавалку, это реально нечитабельно!

Есть пдф-ка в дистрибутиве Qi. http://qilang.googlecode.com/files/Qi9.2.zip

> Я вот, например, пока пользы от них не увидел.

В том виде, в котором они есть в хаскелле, от них действительно не так много пользы.

> Проблема решается написанием шаблонов, которые не захватывают имена переменных. Тоесть, тут я не вижу никаких проблем.

Потрбеностей в колбасе нет? :)

Зачем колбаса, если есть парная свинина и телятина и тд?

>Есть пдф-ка в дистрибутиве Qi. http://qilang.googlecode.com/files/Qi9.2.zip

Так на много лутше :)

>Потрбеностей в колбасе нет? :)

Про колбасу не понял. Что есть колбаса?

Онанимус намекает на старый анекдот, советских времён, про то, что колбасы (вар. икры) в магазине нет, потому что нет в ней потребности - вы же видите, никто её не спрашивает?

Другой вопрос, что этот аргумент в точно той же мере применим к Лиспу и статической типизации, что возвращает нас на исходные позиции.

Только тут не понятно, как это увязывается с именами переменных. С именами переменных я реально проблем не вижу.

> Только тут не понятно, как это увязывается с именами переменных. С именами переменных я реально проблем не вижу.

Ну тут может быть 2 ситуации:

1. hygenic templates - т.е. захвата имен переменных не происходит, но тогда должно быть что-то позволяющее имя переменной захватить, если нужно (что-то вроде dynamic scoping в лиспе).

2. unhygenic templates - обратная ситуация, захват имен может быть, поэтому нужна какая-нить функция вроде gensym в лиспе - makeName, например, для предотвращения этого.

Т.е. в любом случае проблема должна решаться, так или иначе. Предполагаю, что решение есть :)

А прочитать чуть выше - никак?

> А прочитать чуть выше - никак?

Ну дык один говорит - одно, другой - другое, непонятно кому верить. Как нелюбитель хаскелля, выбрал вариант SVOLOCH'и, а он, сволочь такая, оказался неправ :). В хаскелле оказалось с этим все в порядке.

>hygenic templates

Если шаблон генерирует функцию или любое другое значение, то её можно генерировать как лямбду, а все имена переменных буду в списке аргументов и в блоках let/where. Никакого засирания глобальной или локальной области видимости нет.

unhygenic templates

В шаблон можно передать имена переменных и чеголибо есчё, напрмер, имена типов, классов, конструкторов в виде строк. На основе этих строк сгенерировать фрагмент программы в котором будут задействованы имена указаные в аргументах шаблона. Пространство имён тут засирается, но не безколнтрольно.

Особый случай это когда какаято переменная передаётся в шаблон по имени и это имя ВНЕЗАПНО совпадает с локальными переменными того что сгенерировал шаблон. Тут могу посоветовать «не делай так больше».

И вопрос остаётся открытым: где тут вообще проблема?

>Особый случай это когда какаято переменная передаётся в шаблон по имени и это имя ВНЕЗАПНО совпадает с локальными переменными того что сгенерировал шаблон. Тут могу посоветовать «не делай так больше».

Что значит не делай так больше? Я не обязан знать внутренности шаблона, что-бы им пользоваться.

http://www.linux.org.ru/jump-message.jsp?msgid=4377380&cid=4390267

Есть функция, выдающая гарантированно уникальное имя. Как и в Лиспе.

Miguel (*) (02.01.2010 2:33:03)

>>Особый случай это когда какаято переменная передаётся в шаблон по имени и это имя ВНЕЗАПНО совпадает с локальными переменными того что сгенерировал шаблон. Тут могу посоветовать «не делай так больше».

Что значит не делай так больше? Я не обязан знать внутренности шаблона, что-бы им пользоваться.

Вопервых это уже видно по интерфейсу, так что во внутрености можно и не смотреть. Во вторых если ими таки пользуешся то ССЗБ.

По аналогии напомню что в perl5 зарезервированы переменные $a и $b (точно не помню, давно на нём писал)

В любом случае если шаблон написан подыбильному, в него вникать таки придётся. Потомучто это проблема пользователя шаблона а не автора (ибо нефиг такими шаблонами пользоватся).

>В любом случае если шаблон написан подыбильному, в него вникать таки придётся. Потомучто это проблема пользователя шаблона а не автора (ибо нефиг такими шаблонами пользоватся).

Это проблема автора шаблона. Таких авторов надо на дыбу всех.

>Это проблема автора шаблона.

С этим не согласен. Проблемы индейцев вождя не е^Hволнуют.

Таких авторов надо на дыбу всех.

А вот с этим согласен. И не просто согласен, а категорически за.

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

Для тех кто не следует этим рекомендациям повторю есчё раз:

«не делай так больше»

PS

Чтобы развеять сомнения о пользе шаблонов приведу примеры где они полезны. Мне как любителю XML был бы очень полезен шаблон принимающий строку с XPath и конвертирующий её в данные HXT. А есчё очень удобно было бы чтобы шаблон по регулярному выражению генерировал данные Parsec. Другие примеры приведу когда вспомню.

Мне как любителю XML был бы очень полезен шаблон принимающий строку с XPath и конвертирующий её в данные HXT.

Haskell-way - делать наоборот.

http://www.demotivation.ru/4cgzjst7z2c2pic.html

Демотивирует учить ваш C++

>Демотивирует учить ваш C++

для фп даже таких вакансий нет. знание c++ позволит покушать, а не сдохнуть с голода.

>Демотивирует учить ваш C++

А отсутствие вакансий по ключевым словам «Haskell»,«Lisp»,«Scheme» очень даже мотивирует... да...

Хорошо хоть на javascript какойто спрос есть.

http://uisoft.info/metaclass/thesz.jpg

Если изучать ФП - то нужна хорошая книга/курс лекций. Язык вторичен - в идеале там может быть просто мат-нотация или нечто минималистичное - нечто а-ля Scheme (вернее сказать - учебный диалект Scheme). Мне понравились книжки, где «разрабатывался» интерпретатор Scheme на самой же Scheme (таких книг как минимум две) - причем код интерпретатора усложеняется по мере чтения - приводится его преобразование к версии с трамплином и тп. - короче весьма увлекательно.

>http://uisoft.info/metaclass/thesz.jpg

Это наверное самый эпичный демотиватор что я видел =)

>сколько там десятилетий common lisp исчезает?

http://en.wikipedia.org/wiki/Common_Lisp

Appeared in   1984, 1994 for ANSI Common Lisp

Таким образом Common Lisp'у 26 лет и 16 лет с момента стадартизации.

> http://uisoft.info/metaclass/thesz.jpg

Хм, логично - у программиста на Хаскелле дофига свободного времени - работы на этом языке нет - вот он и идёт в зал ;)

спасибо КЭП

>на других платформах возможно стоит присмотреться к Clozure CL (например, под виндой есть нормальные потоки, в отличие от SBCL)

а ему зачем-то хрюшу подавай как минимум =\

Все эти языки очень похожи
по синтаксису и возможностям (+- всякие вкусности).
Если не хочешь, чтобы мертвым грузом лежало, изучай Lisp - он
более-менее распространён.
Лично я Python предпочитаю, сам не знаю почему.
Тут всё слишком субъективно.

>Все эти языки очень похожи по синтаксису и возможностям (+- всякие вкусности).

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

С точки зрения биохимии между уткой и медведем разницы практически нет...

Большая разница - это между ассемблером и C#. Тут действительно различное назначение и реализация.

Lisp действительно сильно отличается. Но я имел в виду кучу новых языков типа Haskel, Ocaml, Ruby... Может их авторы и пытались сделать что-то особенное, но по-моему всё слишком однообразно.

Haskel - развитие академического языков ML/Miranda, в которых были «ленивые» вичисления а так же работа с бесконечными последовательностями, строгая типизация. Я слышал, что этот язык используется ещё и для обучения.

Ocaml - дальний родственник того-же ML (был ещё язык CaML). Вроде как универсальный язык: тут и ООП, и функциональное программирование.

Ruby - разрабатывается как альтернатива Perl и Python. Полностью ООП-язык с функциональными возможностями. Отсутствуют указатели и типы-перечисления.

До Scheme и Smalltalk у меня ещё руки не дошли, но судя по текстам программ на них, радикальных отличий нет.

Предлагаю перед тем, как излагать теории по ЯП, выучить как пишутся названия этих самых ЯП. Например, в слове Haskell две буквы l ;)

Вот какого чёрта в Scheme имя функции по дурацкому соглашению — просто первый элемент в строке термов, никак не выделенный от своих аргументов? Как это хоть сколько-нибудь отвечает парадигме? Это лишь привносит путаницу.

Знаю я, что Haskell! Опечатка была.
И я не «теории по ЯП» излагал, а языки сами описывал.

>С точки зрения биохимии между уткой и медведем разницы практически нет...

С точки зрения <ояебу кого>, компиляторы хаскеля и лиспа - последовательность байт. Ну и?

Lisp действительно сильно отличается. Но я имел в виду кучу новых языков типа Haskel, Ocaml, Ruby...

епт... лисп уж скорее больше похож даже на питон, чем на хаскель. В один ряд хаскель с руби ставить - это таки ппц.

ЗЫ это такой троллинг что-ли?