Glasgow Haskell Compiler 6.8.1

Когда оно разделяемые библиотеки научится?

Ну, hs-plugins есть уже очень давно. А со стороны языка такая поддержка думаю не скоро будет.

>А со стороны языка такая поддержка думаю не скоро будет.

Стоп. То есть это язык обязывает делать бинарники по 100 мегабайт?

> Набор GHC доступен для GNU/Linux, *BSD и альтернативных ОС.

Как я понимаю, альтернативная ОС - это Windows?

> Ну, hs-plugins есть уже очень давно. А со стороны языка такая поддержка думаю не скоро будет.

не надо ляля, все уже есть давным-давно

http://hackage.haskell.org/trac/ghc/wiki/Commentary/PositionIndependentCode

http://hackage.haskell.org/trac/ghc/wiki/DynamicLinking

http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries

Действительно ля-ля.

> Когда оно разделяемые библиотеки научится?

уже может. Но еще не все там налажено, насколько мне известно

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

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

gcc копец назревает??

Отличная новость!! Прямо настроение поднялось :)

Ждем стабильных dll и поддержки solaris x86_64, fbsd x86_64...

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

Ну Вы еще скажите что вендекапеца не было...

По теме: эээ... ждем ебилдов! Еще бы slotted оно было, а то с 6.4 на 6.6 переход был довольно неприятным...

s/оптимизирующих компилятор/оптимизирующий компилятор

ну все.. кому то уж точно капец от такой новости)

>gcc копец назревает??

Конечно! Вот перепишут ядро на хаскелле и гццкапец.

Капец, вероятнее всего, самому Хаскелю. Императивный код на нём -- тихий ужас; библиотеки, предоставляющие всяческую императивную функциональность -- УЖАС.

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

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

А зачем ???

3d рейтрейсер вроде был на Хаскелле. http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html

И движок какой-то Квакоподобный.

>А зачем ??? оно естественно параллелится.

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

На хаскеле уже есть: http://haskell.org/haskellwiki/Frag

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

> А зачем ???

Затем, что это какой-никакой, но показатель. ;-)

>Затем, что это какой-никакой, но показатель. ;-)

чего показатель ? Теперь крутизна языка меряется не по его нише - а по тому пишут ли на нем быдлоигрушки ?

> чего показатель ? Теперь крутизна языка меряется не по его нише - а по тому пишут ли на нем быдлоигрушки ?

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

> быдлоигрушки ?

быдлоanonizmus ?

>Затем, что это какой-никакой, но показатель. ;-)

По вашей логике все языки кроме цпп - атстой. Потому что 99% игрушек для ПК пишут на нем.

> По вашей логике все языки кроме цпп - атстой. Потому что 99% игрушек для ПК пишут на нем.

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

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

а функциональщина неплохо подходит для демонстрации 3d приложений и многоядерников :)

Интересно, когда на Хаскелле станут писать шейдеры?

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

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

Тогда вопрос: почему этого до сих пор никто не сделал?

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

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

Ладно-ладно, пусть будет просто куча legacy кода.

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

Метод Гаусса. Берём элемент a_{11}, прибавляем к строкам 2..n 1-ую, умноженную на -\frac {a_{i1}} {a_{11}} - это list comprehension, потом рассматриваем подматрицу A, полученную вычеркиванием 1-ых строки и столбца, и применяем алгоритм к ней. Для матрицы размерности 1 не делаем ничего.

2Bohtvaroh (*) (04.11.2007 22:32:10):

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

На Хаскеле нескоро, в силу непрактичности языка. На Лиспе, например,

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

Да!

Недавно точно такую реализацию на схеме по чисмет.-лабам сдавал. Только ещё выбор a_{11} надо добавить.

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

2Joe_Bishop (*) (04.11.2007 23:48:31):

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

Да-да. Свежо предание. Ждите ещё лет 50. Числодробильню на ленивом Хаскеле с непредсказуемым временем выполнения задачи. Насмешили. Лучше уж Common Lisp. Пошустрее будет. На Хаскеле не то что числодробильню, несчастный darcs через заднее место приходится оптимизировать, забывая про красоту ФЯ :-)

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

2Midael (*) (04.11.2007 20:15:32):

>> А со стороны языка такая поддержка думаю не скоро будет. > Стоп. То есть это язык обязывает делать бинарники по 100 мегабайт?

А что Вас так волнует? Вы его на программируемом калькуляторе собираетесь гонять? Если у Вас крупный серьёзный проект, какая нафиг разница, 10 мегабайт бинарник или сто? Здесь другие критерии важны.

2anonymous (*) (04.11.2007 22:39:04):

>> 3d рейтрейсер вроде был на Хаскелле. http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html

И что, что 3d рейтрейсер на Хаскелле? Единственное его назначение там -- это пропиарить OCaml, который толкает всем Jon Harrop.

Идёте немного дальше и радуетесь, зачем он там есть:

http://www.ffconsultancy.com/languages/ray_tracer/results.html

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

Оптимизатор говоришь... Тут ведь такое дело --- способ оптимизации зависит также и от данных к которым применяется алгоритм. А они на этапе компиляции не известны (в качестве тупого примера могу привести операции с матрицами, там оптимальные алгоритмы зависят от размера этих матриц). Ну а обогнать фортран и С не получится --- чудес не бывает. Функциональный подход замечателен тем, что существенно упрощает написание программы. Если надо выжать из железа все, то использовать для этого Haskell --- безумие. Я готов признать свою ошибку, если кто-нибудь изготовит подобие BLAS на хаскеле, который будет работать в 2 раза быстрее самой быстрой реализации на С или фортране.

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

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

> (в качестве тупого примера могу привести операции с матрицами, там оптимальные алгоритмы зависят от размера этих матриц)

блочные алгоритмы тоже замечательно описываются на ФП. Имхо, намного удобнее чем на любом императивном.

> Числодробильню на ленивом Хаскеле с непредсказуемым временем выполнения задачи.

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

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

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

> Императивный код на нём

Анонимус! При всём моём к тебе уважении, писать императивный код на Хаскелле - это надо сильно удариться головой об угол.

> Я готов признать свою ошибку, если кто-нибудь изготовит подобие BLAS на хаскеле, который будет работать в 2 раза быстрее самой быстрой реализации на С или фортране.

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

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

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

2balodja (*) (05.11.2007 6:36:45):

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

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

Тут много анонимусов, всех не упросишь. Но с тем, кто сказал, что писать на Хаскеле императивный код -- это коряво, я согласен. И без того синтаксис уродский, а уж императивщина вообще выглядит ужасно. У чисто функциональных языков нет никаких особенных преимуществ перед языками гибридными, вроде Common Lisp. Скорее больше недостатков. Во всяком случае жизнь показывает, что серьёзных проектов на Хаскеле не сделаешь. Разве что сам компилятор GHC, ну так в него сколько ресурсов вбухано. У Microsoft денег много :-) При попытке писать функционально "красиво" получаем захлёбывающийся darcs, где, чтобы не утонуть, про красивость как-то пришлось забыть.

Практичные и в то же время красивые языки -- это Common Lisp, Ruby и Python. При чём в первом уже давно есть всё, что только появилось или появляется в более молодых языках.

Есть игрушки для PS2 написаные на лисп-подобном DSL, работаюшем на Allegro CL.

> Практичные и в то же время красивые языки -- это Common Lisp

Практичный — согласен, но красивым его называть — это перебор. Отдельные пространства имён для функций и переменных, но при этом нет отдельных пространств имён для отдельных модулей. Древняя спека, которая никогда не обновится. Да ещё и имена библиотечных функций там выбраны с изрядной долей циничной фантазии: за DEFUN, SETQ и RPLACA хочется найти старину Маккарти, взять за шиворот, отволочь в Эрмитаж, и не выпускать, пока у отмороженного быдломатематика не пробудится, наконец, чувство гармонии и красоты. Лучше поздно, чем никогда!

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

izvestnyj troll na c.l.l

> за DEFUN, SETQ и RPLACA хочется найти старину Маккарти, взять за шиворот, отволочь в Эрмитаж, и не выпускать, пока у отмороженного быдломатематика не пробудится, наконец, чувство гармонии и красоты.

Eto old-school.

from PCL:

When the place given to SETF is a CAR or CDR, it expands into a call to the function RPLACA or RPLACD; some old-school Lispers—the same ones who still use SETQ—will still use RPLACA and RPLACD directly, but modern style is to use SETF of CAR or CDR.

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