Glasgow Haskell Compiler 7.6.1

Оно?

интересный хак - но не оно:)

Вообще совсем не оно, или немного не оно?

Вообще совсем не оно, или немного не оно?

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

Но делает то что надо со 100% внешней мимикрией :)

Ну, я про мимикрию и говорил. Это-ж костыль-эмулятор.

одного из самых мощных и развитых на сегодняшний день компиляторов функционального языка программирования Haskell

Я бы сказал, единственного, что-то стоящее собой представляющего.

Алсо, не мешало бы ему начать бегать трусцой.

За что люблю хацкель, так это за примеры с фибаначами! А для человеческого программирования юзаю цэшарп. :)

Про плюсы от функционального программирования начитан

эээ... вы про тот единственный плюс распараллеливания, которым мне все глаза утыкали? Ну, допустим. Однако, это такое же преимущество, как делать колёса из среза бревна - «его не нужно округлять». А что, распараллеливать можно ТОЛЬКО в ФЯ?? Уже сто лет существуют элементарные Threads. Там, где прогер считает нужным, он их спокойно применит. Зачем для этого ломать мозг абсолютно ортогональной мышлению идеей функций? Мы мыслим императивно, соотв. твой «последовательный» код будет понятен ещё тысячам сотрудников. Это главное. А как хобби - да, можно даже и побрэйнфакать.

Идеальным видится программирование не ремесленное как оно сейчас (императивное в основном и потому не естественное для человека), а именно математическое - как в Haskell - к примеру на основе той же математики функций.

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

Мы мыслим императивно, соотв. твой «последовательный» код будет понятен ещё тысячам сотрудников.

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

А управляемая иммутабельность позволяет лучше следить за корренктностью, достаточно сравнить уровень type-checking-а явы или шарпа, хотя бы с haskell? что тоже очень большой бонус.

matumba

Мы мыслим императивно

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

Плюсы Haskell [...] в меньших затратах на тестирование

Гладко стелишь. Ленивость может преподнести сюрпризы при тестировании, большие сюрпризы.

Ленивость обеспечивает скорость работы кода, и не согласен в что она дает сюрпризы, которые сложно предугадать.

Значительно больше проблем имеем от побочных эффектов, и их предугадать или даже отдебажить очень сложно даже опытному программисту.

Если бы не было проблем вообще никаких, то затраты на отладку были бы нулевые, а пока они для Haskell и Erlang заметно ниже и совсем в другой плоскости.

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

А меня ленивость один раз здорово удивила. Я несколько часов не мог понять, почему моя программка на хаскеле отжирает всю память. Потом дошло, что дело в отложенных вычислениях. Как добавил seq в паре нужных мест, все заработало.

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

но простым смертным иногда нужны именно побочные эффекты.

Так говоришь, как будто в хаскеле их _вообще_ нет :)

А меня ленивость один раз здорово удивила.

Как добавил seq в паре нужных мест, все заработало.

Аналогичная ситуация с lazy io (которое в хаскеле тоже по дефолту):

readFile "foo" >>= writeFile "foo" . process
-- *** Exception: foo: openFile: resource busy (file is locked)

файл «foo» открывается, вычитывание его в строку откладывается, _не_ закрывается (строка же ленивая, чё), но пытается открыться снова. Приходится вручную разъяснять:

readFile "foo" >>= ($!!) (writeFile "foo") . process

при этом если забыть скобки и написать

readFile "foo" >>= ($!!) writeFile "foo" . process

то всё cкомпилируется, но опять будет exception, так как это

readFile "foo" >>= \str -> (writeFile $!! "foo") {- <- строгость для "foo", а не для process str -} (process str)

Я просто пытаюсь представить, какие муки ожидают того, кто осмелится написать хотя бы редактор диаграмм на хаскеле. Там полезнее будет погрязшее в нечистотах ООП, чем чистоплюйское ФП в редакции хаскеля.

Ленивость обеспечивает скорость работы кода

Дело не в скорости - будь это так, все остальные языки уже бы перешли на ленивость и вообще эта стратегия практиковалась бы изначально, зачастую ленивый алгоритм будет медленнее строгого (на эту тему есть paper с бенчмарками про optimistic evaluation которое не сделали в GHC исключительно потому что это трудно сделать в его существующей кодовой базе) и памяти потреблять будет больше (история с foldl и foldl'). Просто есть класс алгоритмов которые возможно написать лениво (не строго) и невозможно строго.

Скорость в хаскеле как раз предполагает использование строгой стратегии - строгие типы данных (bytestring, text, aeson, vector - все строгие), bang patterns в типах данных, seq, ($!), deepseq, bang patterns в определяемых функциях и лямбдах, strategies.

не согласен в что она дает сюрпризы, которые сложно предугадать.

Предсказать как ленивая программа будет потреблять память зачастую довольно сложно - остаётся только смотреть в профайлере.

Я просто пытаюсь представить, какие муки ожидают того, кто осмелится написать хотя бы редактор диаграмм на хаскеле

Или, например, оптимизирующий компилятор хаскеля. Wait... :)

Для диаграмм, как я понимаю, нужна какая-то морда (явно не веб, потому что в этом случае это будет не хаскель а javascript, qt / gtk / opengl / wx? к последнему даже есть FRP обвёртка), event loop который будет превращать события в (чистые, надо сказать) функции «диаграмма» -> «диаграмма» (где «диаграмма» это модель видимой диаграммы в типах данных), которые будут применяться на объекте «диаграмма» висящем где-нибудь в STM. То есть такое MVC получается (мутабельная ссылка с моделирующим типом данных, преобразующие функции и event loop с мордой). Скорость морды - не проблема, скорость и потребление памяти обновляющими модель функциями (ленивыми или строгими) это вопрос, они, видимо, должны сохранять в модели как можно больше данных о связях, чтобы при последующем построении уменьшить его сложность, ещё вопрос в том как быстро будет обновляться сложная структура внутри мутабельной ссылки при обновлении только небольшой её части, сериализацию можно делать с binary, форся диаграму перед этим с помощью deepseq (если она и так не строгая и не обрабатывается строгими функциями).

Там полезнее будет погрязшее в нечистотах ООП, чем чистоплюйское ФП в редакции хаскеля.

Хаскель не только «чистый функциональный», но и datatype ориентированный, императивный и конкурентный.

Мы мыслим императивно

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

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

Помечтать, конечно, можно :) Только если делать хороший редактор диаграмм уровня MS Visio или Google Docs, то там хватает сложностей помимо тех, что привносит сам выбор языка программирования. Строго говоря, по-моему задача все-таки не для ФП. Например, для внутреннего представления диаграмм характерно большое количество обратных связей, а они императивны по сути.

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

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

Иммутабельно это делается с помощью tying the knot:

data A = A B
data B = B A

loop :: A
loop = A b where b = B loop

мутабельно - точно так же как и где-нибудь в си, то есть используя семантику указателей:

data A = A (IORef B)
data B = B (IORef A)

loop :: IO A
loop = do
  ar <- newIORef undefined
  br <- newIORef undefined
  writeIORef ar $ B br
  writeIORef br $ A ar
  return $ A ar

Это я знаю. Вопрос в том, что в общем случае действительно понадобится IORef, а она на вид ужасно громоздка со своими императивными вычислениями IO :)

Нет, можно и ООП сымитировать на IORef. Один модуль - один класс. Слот - это поле записи с IORef. Но от такой схемы возникает какое-то ощущение неправильности происходящего, если такие классы составляют основу приложения. Не лучше ли было выбрать другой инструмент? И ты, наверное, знаешь какой :)

Иммутабельно это делается с помощью tying the knot

При этом в энергичном языке сделать циклическую иммутабельную структуру таким образом просто нельзя (не получится «завязать узел»), возможен только второй вариант:

a_struct->to_b = b_struct;
b_struct->to_a = a_struct;

аналогично двум строчкам с writeIORef. Это пример того что позволяет сделать ленивость (другой пример - бесконечные структуры данных).

Циклические иммутабельные структуры - это вырожденный случай. Красиво на бумаге, но на практике нужен IORef.

а она на вид ужасно громоздка со своими императивными вычислениями IO :)

Можно сделать себе new, =: и постфиксный *, чтобы было привычно. Хотя будет нудно, да - в обычном императивном языке императивные конструкции могут быть вложены, а в хаскеле вместо *x + *y + *z нужно в лучшем случае писать liftM3 (+) (x *) (y *) (z *) (или перегружать (+)), в худшем - do-портянку.

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

Если так делать - да. Если выбрать более гармоничные для хаскеля методы проектирования - будет лучше. Не скажу про GUI со связными объектами, но задачи вида вход -> выход (разные трансляторы) или запрос -> ответ (конкурентные сервера приложений) вполне получается писать.

И ты, наверное, знаешь какой :)

Общелисп? Судя по примерам макросов из треда в development. Кстати, что-то подобное можно и на TH изобразить (по крайней мере с точки зрения генерации группы функций для типа данных по такого рода декларативным описаниям).

Если так делать - да. Если выбрать более гармоничные для хаскеля методы проектирования - будет лучше. Не скажу про GUI со связными объектами, но задачи вида вход -> выход (разные трансляторы) или запрос -> ответ (конкурентные сервера приложений) вполне получается писать.

Здесь я согласен. Есть задачи, где хаскель может быть хорош. Мне кажется, что волна интереса к ФП в целом связана с тем, что за последние лет пятнадцать умопомрачительно возрос спрос на серверное ПО, а там должно быть много таких задач. Я же больше занимаюсь десктопами - так исторически сложилось (кстати, не подскажешь интересную серверную задачу для жаст-фо-фан?).

Общелисп? Судя по примерам макросов из треда в development. Кстати, что-то подобное можно и на TH изобразить (по крайней мере с точки зрения генерации группы функций для типа данных по такого рода декларативным описаниям).

Там была выдержка из хобби-проекта. А, вообще, я серьезно рассматриваю LispWorks и AllegroCL для написания кросс-платформенных десктопных приложений.

А что, распараллеливать можно ТОЛЬКО в ФЯ?? Уже сто лет существуют элементарные Threads. Там, где прогер считает нужным, он их спокойно применит.

Але, ты вообще в каком веке живешь? Threads давно не котируются. Рулят polyhedral модели. А они, естественно, на 100% императивны. Функционанисты ничего им противопоставит так и не смогли, хи хи хи.

Ты, вероятно, не в курсе, но все люди мыслят императивно. Даже самые опущенные и тупые функционанисты. Именно по этой причине функционанисты так и не осилили написать ничего полезного, они пытаются переть против природы.

Судя по примерам макросов из треда в development. Кстати, что-то подобное можно и на TH изобразить (по крайней мере с точки зрения генерации группы функций для типа данных по такого рода декларативным описаниям).

Самое забавное там, что аналогичный код на Scala примерно такой же по объему, но он содержит саму реализацию, а не макросы. Вообще, Scala очень лаконична, но, к не счастью, JVM.

не подскажешь интересную серверную задачу для жаст-фо-фан?

И чтобы не веб? А то это тот же десктоп, только в браузере. Каких-то простых интересных задач не вспомню, ели ограничиваться tcp/ip, то всё довольно банально - протокол, запрос, ответ. С сетями может быть интереснее, можно попробовать что-нибудь на тему p2p gridов - свой велосипед для дистрибуции файлов и вычислительных ресурсов (в духе erlang / akka).

С формальной точки зрения вообще не оно:) Но делает то что надо со 100% внешней мимикрией :)

1. nobody cares насчет формальной точки зрения

2. с внешней мимикрией тут тоже не все гладко

рассмотрим, скажем, внешнюю библиотеку proprietory.h без исходников, предоставляющую функцию int my_rand(); пусть, также, у нас есть некое количество кода, заюзавшее этот библиотечный my_rand; далее стоит задача ДОписать свой char* my_rand() так, чтобы my_rand стал полиморфен по возвращаемому значению, а прошлый наш код переписывать не пришлось

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

далее можно рассмотреть более интересный случай, когда есть proprietory.hxx и в ней нестатический метод int SomeClass::my_rand(); тут опять можно попробовать выкрутиться перегрузкой оператора ->, но результаты этот борьбы с с++ уже плохо предсказуемы

и наконец, похоже наиболее сложный случай int SomePolymorphicClass::my_rand()

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

Спасибо! Буду думать. Диссертацию просмотрел. Тут и имитационное моделирование, тут и bittorrent. Кстати, а зачем еще один велосипед? :)

Кстати, а зачем еще один велосипед?

Как раз для фана :) Потом, любой велосипед имеет право на жизнь при отсутствии (да даже и при наличии) полностью готовых решений. Тот же Erlang появился как «распределённый пролог» в CS лаборатории при Ericsson. Если не брать целые ОС вроде Plan 9 (который всё равно не используется), то есть ли сейчас какой-нибудь кроссплатформенный middleware общего (то есть не какой-нибудь специальный софт для научных гридов) назначения работающий где-нибудь на седьмом уровне OSI (как bittorent или git, например) и предоставляющий разным языкам унифицированный API для написания распределённых приложений - авторизация + файловые системы + вычисления? Есть набор несвязанных средств позволяющий добиться нужного (до изобретения «распределённого пролога» тоже, видимо, был «набор средств»). Для Java и Scala есть akka, есть Erlang, который сам по себе, но оба они для распределённых вычислений, то есть не покрывают нужды в авторизации и файловых системах. Впрочем, ФС можно построить поверх акторов сделав файловые сервера принимающие сообщения про файловые операции. Но тут могут быть варианты, например, объект /$node/proc/$pid может принимать сообщения вроде kill, message «foo» и migrate, с другой стороны, объект /$node/fs/$file тоже может принимать подобные сообщения delete, write/append «foo» и mv, кроме того, имеет право на жизнь объект /$network/fs/$file с сообщением mv которое будет работать как get из DHT, наконец, нельзя ли придать /$network/proc/$name подобный DHTшный смысл (должны быть подобные процессы (map?) которые можно параллельно опросить (reduce?) аналогично параллельному получению файла из сети)?

Как я и писал ранее, с Haskell я знаком лишь по книгам, надеюсь лишь только пока.

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

В ремесленной своей жизни приходится отлаживать «индусский» код императивной парадигмы, отлаживать и дебажить приходится одни и теже фукнции и методы по многу раз, причем уже после того как считается, что они якобы на 100% проверены, и все «счастье» именно из-за «побочных» эффектов. Про рекурсию, реализуемую в императивной парадигме - ее стараются по возможности просто не использовать и не важно что код при этом становится сложным и не читаемым - и это общеизвестный факт излагаемый во всех курсах по «ремесленному» программированию.

Но отмечу, что в Haskell фукнкция будет себя вести одинаково при тех же параметрах.

Например, падать при одних и тех же параметрах :)

Но отмечу, что в Haskell фукнкция будет себя вести одинаково при тех же параметрах

М, нет, не будет.

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

На сцену выходит Диванный Эксперт.

Нет, можно и ООП сымитировать на IORef. Один модуль - один класс. Слот - это поле записи с IORef.

Кстати, нельзя - модули не инстанцируются (не параметризируются), IORef не может быть в top-level (только с хаком в виде unsafePerformIO + NOINLINE). Скорее CLOS можно моделировать - несколько defclass это один data c TVar/MVar/ST/IORef для мутабельных полей (функции в слотах будут такими же функциями в конструкторах), defun ~ определение функции, defgeneric ~ class, defmethod ~ instance, динамическая диспетчеризация ~ instance для GADTs/Existential.

Боюсь, что не потяну такое громадище. Мне бы какую-нибудь простую и ясную задачу. Желательно для лиспа (фан же). Но все равно спасибо за участие.

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

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

ну чтож в gentoo/haskell-overlay теперь есть, пока не всё юзабельно, но xmonad можно собрать.

с формальной точки зрения - это обозначает что это костыль.

насрать на формальную точку зрения

а то что это действительно костыль, надо доказывать примерами костыльности — т.е. неполной мимикрии типа того, что привел я

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

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

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

ты не забываешь, что вывод типов должен уметь работать в обе стороны?

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

я не понял, как это относится к тому, что я написал

чуть подробнее что я имел в виду: если:

1. в языке есть довольно мощный вывод типов

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

3. вывод типов не проектировался для того, чтобы обеспечивать полиморфизм по типу результата с помощью добавления в стиле my_rand

4. кто-то все же написал добавление в стиле my_rand

то добавление в стиле my_rand почти наверняка будет интерферировать с выводом типов, т.е. окажется костылем

Желательно для лиспа

Тогда что-нибудь вроде http://tryruby.org, только для CL? 1) Протокол для s-выражений поверх HTTP, 2) js (<- parenscript) библиотека на стороне клиента, 3) общение в стиле comet, 4) песочницы и сессии на стороне лиспового сервера (тут должна быть самая магия, если не форкать по интерпретатору на каждую сессию и не решать вопросы безопасности средствами ОС). Либо учить swank вебсокетам и общаться по его протоколу (вместо 3 и 1), но тоже с js у клиент и сессиями-песочницами поверх swank.

Интересная идея. Мне бы такое, что можно было бы коммерциализировать при удачном стечении обстоятельств, но при этом важен фан. Думаю, может быть, не серверное, а какое-нибудь десктопное приложение, но идей хороших у меня на сей счет нет.