Glasgow Haskell Compiler 6.8.1

> Eto old-school.

Ладно, пусть так, но в спеке они есть и в глобальном пространстве имён присутствуют. А сами SETF и СAR/CDR — это верх красоты, что ли? Ну ладно, CAR и CDR я ещё готов простить, потому что для всяких CADDR трудно придумать другие имена. И то, если язык, претендующий на метапрограммирование искаропки, содержит кучу функций с похожими именами и похожей функциональностью, то следовало бы предусмотреть _красивый_ способ создания таких функций без копипаста. Но если бы этим CAR/CDR всё ограничивалось, так нет: PROG/PROG*/PROG1/PROG2/PROGN, MAP/MAPC/MAPCAR/MAPCAN/MAPCON/MAPL/... По-моему, так если в языке появляется столько функций для одной и той же операции, из которых, вдобавок, большая часть на практике не используется, то с языком что-то не так. Весь CL — заскорузлый old school, примерно как Фортран-77.

> В том и сила лиспа. Есть макросы, можешь переделать defun во что угодно.

Если каждый будет переделывать defun во что угодно, наступит разруха. :) Потом, вместо того, чтоб каждому в одиночестве на свой лад исправлять для себя кривизну CL, давно бы лисперам собраться всем вместе и придумать новый лисп с человеческим лицом. Но почему-то выходят всё поделия вроде newLisp.

> альтернативных ОС.

Дожили! Венда - альтернативная ОС =))

Ну дык каждый, кто начинает проект на CL, создает свой "новый лисп с человеческим лицом" и пишет все на нем. Что в этом плохого? :)

Ждем ебилдов

> Ну дык каждый, кто начинает проект на CL, создает свой "новый лисп с человеческим лицом" и пишет все на нем. Что в этом плохого? :)

Любая отсебятина — это всегда плохо. Во-первых, потому что каждому новому человеку, пришедшему в проект, придётся забыть всё, что он знал до этого, и осваивать очередную куль платформу (и потом держать всё это в голове). Во-вторых, на то, чтоб поддерживать все эти самодельные мегафреймворки, уходит куча времени и сил. Это не только лиспа касается. В каждой большой корпорации и в каждом большом проекте на С, C++ или Яве есть мильён своих неповторимых костылей. Как правило, они там используются ещё с незапамятных пор, и устарели ещё 10 лет назад, но избавиться от них нереально, потому что проще переписать всё с нуля. Это очевидный признак убогости языка в контексте решаемой задачи. И в этом смысле CL убог. Почему вот питоновские проекты (ну, кроме Zope) не обрастают самописными костылями со временем, а спокойно пользуются стандартной библиотекой и PyPI? :P

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

on bydlokoder? :)

po lyubomu pridetsya osvaivat'. Panacei net.

> on bydlokoder? :)

> po lyubomu pridetsya osvaivat'. Panacei net.

Отнюдь не по-любому, если будет один нормальный язык на всех. Питон ведь работает из коробки, и не надо его допиливать.

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

> Отнюдь не по-любому, если будет один нормальный язык на всех.

Многословная Java?

А с лиспом обратную картину представить очень трудно: это каким надо быть идиотом, чтобы часто встречающуюся функциональность / требуемые фичи в данной области не "звернуть" в библиотеки макр/функций. Не зря все бубнят заученную мантру "DSL" - нах использовать лисп чтобы писать как на Java?

А то что нет унификации многих вещей - да, иногда приходится сначала перелопатить всё что найдёшь на требуемую тематику и выбрать наиболее подходящее, возможно допилив под себя. Это в корне отличается от "нашёл в доке, ознакомился и используй - ни шага в сторону". Иногда последний вариант может и быстрее, но всегда ли оптимальнее?

> Многословная Java?

При чём тут ява? :) Я имел в виду некий Новый Правильный Лисп, который будет лучше, чем CL и Схема.

> А с лиспом обратную картину представить очень трудно: это каким надо быть идиотом, чтобы часто встречающуюся функциональность / требуемые фичи в данной области не "звернуть" в библиотеки макр/функций

Это само по себе всё здорово. А плохо когда для одной и той же задачи каждый делает свой собственный велосипед, и это поощряется.

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

Про «ни шагу в сторону» речи не было. Не нравится искоробочное решение — сделай сам, кто запретит? А вот «нашёл в доке, ознакомился и используй» — так и должно быть. Чтоб тратить время не на создание очередных костылей для решения повседневных задач, а на действительно интересные вещи. Ты ведь, наверно, ешь готовый хлеб из магазина и не жалуешься. :)

Кстати, примерно такая же аргументация работает против повсеместного использования DSL. Кое-кто толкает в массы идею, что правильный подход к решению чуть ли не любой задачи -- формулировка и реализация подходящего для задачи языка поверх Лиспа. И многие, похоже, в это свято верят. Забывая, что:

1. Разработка "правильного" языка по определению очень сложная задача. Это верно как для языков общего назначения, так и для проблемно-ориентированных языков, в т.ч. встроенных. Авторы быдлоDSL часто даже не понимают этого, подсознательно выписав себе индульгенцию.

2. Изучение DSL тоже отнимает время. Возможно, хорошо продуманный и к месту применённый язык оправдает затраты. Однако, с учётом пункта 1, на практике всё гораздо печальней.

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

Хаскель очень мощный язык. Настолько мощный, что вылетает с
переполнением стека на ровном месте. Казалось бы, тривиальная хвостовая рекурсия, ан нет, не всё так просто.

main = print (range_sum 1 1000000)

range_sum a b = iterative_sum a 0 where
    iterative_sum x s = if x > b then s
                                 else iterative_sum (x + 1) (s + x)


Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize' to increase it.

Почему так происходит -- понятно (из-за ленивости).
Как лечить, тоже понятно. Но это довольно-таки противоестественно.

Где ты там хвостовую рекурскию нашел?

>> писать императивный код на Хаскелле - это надо сильно удариться головой об угол.

>Вроде бы это одна из сильных сторон хаскеля, не? Давайте лучше попросим анонимного друга показать код, который его так напугал.

Посмотри на библиотеки Хаскеля, работающие с изменяемыми данными. Всякие там MArray и двоичный ввод-вывод. Это же писец полный. Да, наверное очень прикольно это изобретать. А на практике, ну нах такое счастье.

Ещё есть такая подстава -- взрывоподобное переписывание тонны кода из-за того, что где-то понадобилось упорядочить операции. ИМХО, монада IO попросту рушит модульность (инкапсуляцию). Зачем, за каким хреном мне знать, что происходит внутри какой-то левой библиотечной функции? Присутствие IO в сигнатуре открывает никому не нужные детали реализации. Ах да, по другому в ленивом языке сделать сложно. Так может в топку её, ленивость эту.

(Сейчас прибегут хаскеляторы и скажут, что IO не единственная монада, и вообще монады это круто, почти как макросы. Частично, согласен. Но это не отменяет сказанное выше)

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

>Где ты там хвостовую рекурскию нашел?

Хаскеляторы уже не в состоянии найти хвостовую рекурсию
в трех строчках кода? Охренеть просто.

iterative_sum x s = if x > b then s
                                 else iterative_sum (x + 1) (s + x)
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                      Хвостовая рекурсия.

Ну не такой уж я и хаскелятор. А вот уважаемому анонимусу стоит знать, что if/then/else -- это не языковая конструкция. Курим лямбда-счисление.

>А вот уважаемому анонимусу стоит знать, что if/then/else -- это не языковая конструкция.

Извиняюсь, Вы совсем дурак? if/then/else -- как раз специальная языковая конструкция в не ленивых языках, и по сути обычная функция -- в ленивых. Что и приводит к неочевидному косяку.

(define (range-sum a b)
  (define (iterative-sum x s)
    (if (> x b)
        s
        (iterative-sum (+ x 1) (+ s x))))
  (iterative-sum a 0))


Эквивалентная, почти один-в-один программа на Схеме. При вызове
(range-sum 1 1000000) никакого переполнения стека не происходит,
естественно.

> Почему так происходит -- понятно (из-за ленивости). > Как лечить, тоже понятно. Но это довольно-таки противоестественно

Почему это -- противоестесственно?

Всего лишь добавить $! в iterative_sum ... else iterative_sum (x + 1) $! (s + x) ...

На практике такое следует делать через foldl' -- и это совсем не аргумент против ленивости. Хочешь ленивость -- stack overflow, не хочешь stack overflow -- пожалуйста, неленивый вариант.

> и по сути обычная функция -- в ленивых.

Вот ключевая фраза-то. И как после этого можно говорить о хвостовой рекурсии в вышеобозначенном примере на хаскеле?

>Тут ведь такое дело --- способ оптимизации зависит также и от данных к которым применяется алгоритм. А они на этапе компиляции не известны (в качестве тупого примера могу привести операции с матрицами, там оптимальные алгоритмы зависят от размера этих матриц).

Тут будет рулить любой ЯВУ, если его собирать в байт-код, который при выполнении (на больших объемах данных) перекомпилирует подобную матричную функцию, используя оптимальный алгоритм для конкретных входных данных.

Кстати, tail recursion в примере оптимизируется, причем отменно. Что не дает права не быть в курсе того, что язык ленивый.

Да, п**жу, причем по-жесткому. Действительно хвостовая :) Каюсь-каюсь.

Когда уже в нем появятся замыкания и хвостовая рекурсия?

>Почему это -- противоестесственно?

Потому что добавление закорючки $! не несёт полезной смысловой нагрузки. Эта закорючка -- подсказка компилятору; вместо того, чтобы сосредоточиться на задаче ("что надо вычислить" -- сам алгоритм) мы вынуждены объяснять, "как надо вычислить", чтобы не случилось фигни. Лишняя, никому на самом деле не интересная деталь реализации.

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

>На практике такое следует делать через foldl'

foldl1, наверное? Ну так fold1 (+) [1..1000000] тоже вылетит со Stack Overflow.

>Кстати, tail recursion в примере оптимизируется, причем отменно.

Это понятно, на что я сразу указал ("известно как лечить").

>Что не дает права не быть в курсе того, что язык ленивый.

Тоже верно, но необходимость это всегда помнить может раздражать.

> foldl1, наверное? Ну так fold1 (+) [1..1000000] тоже вылетит со Stack Overflow.

Срочно курить доки, не foldl1, а именно foldl'.

> Потому что добавление закорючки $! не несёт полезной смысловой нагрузки. Эта закорючка -- подсказка компилятору; вместо того, чтобы сосредоточиться на задаче ("что надо вычислить" -- сам алгоритм) мы вынуждены объяснять, "как надо вычислить", чтобы не случилось фигни. Лишняя, никому на самом деле не интересная деталь реализации.

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

> При чём тут ява? :) Я имел в виду некий Новый Правильный Лисп, который будет лучше, чем CL и Схема.

Arc-а мы не дождёмся, а если и дождёмся, то это будет не "Новый Правильный Лисп", а лисп Пола - каждый всё равно под себя будет затачивать. А на новый стандарт можно и не рассчитывать.

> А плохо когда для одной и той же задачи каждый делает свой собственный велосипед, и это поощряется.

Многие и так ругаются на размер стандарта - если туда ещё понапихивать всякой всячины... А количество велосипедов определено не "языковыми поощрениями", а количеством реализаций CL, которые местами (особенно не вошедшими в стандарт) различаются очень сильно, и многим было не до того, чтобы писать сразу кроссплатформенные библиотеки.

> А вот «нашёл в доке, ознакомился и используй» — так и должно быть.

Всё сразу никак не напишешь. Иначе к Питону не писали бы сторонние библиотеки :)

>Срочно курить доки, не foldl1, а именно foldl'.

Да, есть такая.

>Попробуй для начала на неленивом языке реализовать какую-нибудь
сложную структуру данных (например, дерево, в котором
все узлы осведомнены о родителях и детях)

OCaml:

type tree = Root (* Fake parent for root node *)
          (* payload, parent, left child, right child *)
          | Node of char * tree * tree * tree
          (* payload, parent *)
          | Leaf of char * tree

let rec a = Node ('a', Root, b, c)
and b = Node ('b', a, d, e)
and c = Leaf ('c', a)
and d = Leaf ('d', b)
and e = Leaf ('e', b)

>докажи, что "ссылка" (или "указатель") является "нужной деталью
реализации"

Э... какие такие ссылки и указатели?
Не вижу никаких ссылок и указателей.

> Вроде бы это одна из сильных сторон хаскеля, не?

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

> Авторы быдлоDSL часто даже не понимают этого, подсознательно выписав себе индульгенцию.

Будем на них ориентироваться / под них подстраиваться?

Хотя с одним согласен: в большой команде это должно строго оговариваться и в дальнейшем согласовываться - что вносится в собственный DSL, а что нет и пишется "в лоб".

А когда пишешь один, то повторение подобного куска кода более двух раз уже режет глаза.

> 2. Изучение DSL тоже отнимает время. Возможно, хорошо продуманный и к месту применённый язык оправдает затраты. Однако, с учётом пункта 1, на практике всё гораздо печальней.

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

Пункт 3-й перечёркивает пункт 2-й - всё равно учить надо. В том-же лиспе разницы нет - что библиотечные функции, что макры. Хотя иногда и синтаксис переворачивают (тот-же CLSQL) - но это довольно редкое явление, к тому-же как правило не обязательное.

Да, Хаскель - хороший пример. Но в одном он уступит лиспам "на все 100%" - макросах - кодогенерации собственного кода "по месту необходимости". Хотя на классах многое делают. Но - вы меня простите... :)

>Дорогой друг, это требование смешно.

Это не мое требование, а оратора выше, который прогонозирует, что по скорости чилодробильни функциональные языки скоро порвут фортран.

>Я не пишу численные программы на хаскеле или любом другом функциональном языке. Я лишь описываю алгоритмы на (фактически на хаскеле + несколько фишек). По такому виду алгоритма очень хорошо видны пути оптимизации, и он очень хорошо перекладывается на C и указатели.

Автоматическая компиляция и ручное переложение на С --- это разные вещи, первая задача значительно сложнее. Компилятор не телепат, и оптимизированный алгоритм на любом сколько-нибудь универсальном языке всегда будет корявым. Могу в качестве упражнения посоветовать на хаскеле реализовать алгоритм быстрой сортировки, который сортирует список на месте (без выделения дополнительной памяти, т.е. так как это делает qsort из libc). Если и получится, то это уже не будет той красивой строчкой из учебников по хаскелю. Я это не к тому, что хаскел гавно, а к тому, что за все надо платить, в частности за оптимизацию расплачиваются читабельностью и размером кода. Другое дело, что во многих случаях эта оптимизация на хер не нужна, и тогда хаскел рулит.

Насчет let rec -- это-то понятно, а вот как будет выглядеть добавление в такое дерево? Подозреваю, что без копирования не обойдетесь.

>как будет выглядеть добавление в такое дерево? Подозреваю, что без копирования не обойдетесь.

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

>Весь CL — заскорузлый old school, примерно как Фортран-77.

А чем тебе Схема не угодила?

> Недеструктивное добавление по-любому подразумевает копирование структуры данных. Деструктивное -- использование переменных. Короче, не понимаю о чём речь. Код на Хаскеле в студию.

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

>Тут будет рулить любой ЯВУ, если его собирать в байт-код, который при выполнении (на больших объемах данных) перекомпилирует подобную матричную функцию, используя оптимальный алгоритм для конкретных входных данных.

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

>Я имел в виду копирование родительских деревьев в дочерние.

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

>В случае кода на хаскеле копирования не произойдет

Копирование чего не произойдет?

>Родители будут вычисляться лениво.

Что значит "вычисляться" применительно к структуре данных? На уровне процессора, поле "родитель" -- это указатель. Даже в Хаскеле.

> Arc-а мы не дождёмся, а если и дождёмся, то это будет не "Новый Правильный Лисп", а лисп Пола - каждый всё равно под себя будет затачивать.

Что-то мы несколько в сторону стали уходить. Речь шла не о пользе/вреде DSL, а о том, что:

- CL уродлив,

- каждый чинит его по-своему, вместо того, чтоб починить сообща,

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

Как, например, макросы помогут мне справиться с отсутствием пространств имён? Или объединить пространства функций и переменных (может, я не труъ, но я этого хочу, и Пол этого хочет).

Лисп Пола обещает быть намного более приятным.

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

Напротив, выкинуть бы половину. А остальное разбить по модулям, примерно как в Питоне. =)

> Лисп Пола обещает быть намного более приятным.

Сцылку пожалуйста. Или это пресловутый newLisp?

http://www.paulgraham.com/arc.html

Оно?

> CL уродлив,

местами и то субъективно.

> - каждый чинит его по-своему, вместо того, чтоб починить сообща

"Чинит" - это дописывает свой инструментарий? А на других языках этого ни кто не делает? А лишь менять имена "корявых" функций - этого никто не делает, практически. А остальные - ССЗБ.

> - но даже макросы не позволяют до конца преодолеть его уродливость.

вот здесь напрочь не догоняю о чём идёт речь.

> Как, например, макросы помогут мне справиться с отсутствием пространств имён? Или объединить пространства функций и переменных (может, я не труъ, но я этого хочу, и Пол этого хочет).

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

И вот видишь - если Пол не компенсирует единое пространство чем-то другим - очень многим его решение не понравится.

> Лисп Пола обещает быть намного более приятным.

В нём станет меньше скобок? :D

> Напротив, выкинуть бы половину. А остальное разбить по модулям, примерно как в Питоне. =)

И? Так трудно завести несколько новых packages, в которых ничего кроме импорта требуемых имён не будет, и использовать только их?

ИМХО, все эти мелочи "не выведут лисп на новую орбиту", а раз так - стоит ли "овчинка выделки"?

>Да нет, просто мне показалось, что раз уж зашла речь о разделяемых библиотеках и компиляторе в нативный код (поправьте, если я не прав, ибо по ссылке не ходил), то 3д приложения как раз неплохо подходят в качестве демонстрации всех этих возможностей. Ну а цпп вообще на ЛОРе персона нон грато. :))

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

>>и альтернативных ОС.

>винда это не alt os

RTFM: http://ru.wikipedia.org/wiki/Альтернативная_операционная_система

> Альтернативная операционная система — операционная система (ОС), разработанная на основаниях, альтернативных стандарту ISO/IEC 9945 (POSIX).

>Интересно, когда на лиспе/хаскелле начнут писать 3д-игрушки? :)

:-)

Давно Lisp уже давно пишут.

В Древние Времена писались разные там Abuse. Более современный пример - Jack the Dexter (для PS2). Наверное их немало, просто про это не принято кричать на каждом углу.

Хаскел наше функциональное фсио!! Особенно прусь от программеров кто кодит на нем, весело смотреть...

2dragon_djanic ** (*) (05.11.2007 20:13:50):

>>> Хаскел наше функциональное фсио!! Особенно прусь от программеров кто кодит на нем, весело смотреть...

LOL :-D

>>Тут будет рулить любой ЯВУ, если его собирать в байт-код, который при выполнении (на больших объемах данных) перекомпилирует подобную матричную функцию, используя оптимальный алгоритм для конкретных входных данных.

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

Ну это уже проблема компилятора (точнее математическая проблема). Однако подобная техника давно известна и описана в вике (статья про самомодифицирующийся код, не помню русская или английская).

Ну чтож.. работы продвигаются.. ;-)