LINUX.ORG.RU

Glasgow Haskell Compiler 7.4.2

 , ,


1

4

Вышла новая версия GHC 7.4.2 — одного из самых мощных и развитых на сегодняшний день компиляторов функционального языка программирования Haskell, который разрабатывается свободной рабочей группой из многочисленных разработчиков, собранных по всему миру и координируемых из лаборатории университета Глазго.

7.4.2 — bugfix-релиз, исправлено более 30 различных ошибок в компиляторе, интерпретаторе и библиотеках.

Подробный список изменений

>>> Подробности

★★★★★

Проверено: tazhate ()
Последнее исправление: mono (всего исправлений: 2)
Ответ на: комментарий от aptyp

в 7.4.1 пофиксили, но почему то для винды версия 7.0.x

Дык це ж разве баг? Нехрен, Артур, использовать имя пользователя «артур».

ЗЫ: Хотя да, дефолтное поведение show ЗАДАЛБЫВАЕТ.

Кстати, есть похожий баг: в виндовой консоли не работают команды ghci :t и :i если в типовых сигнатурах есть юникодовские символы. И это тоже связано с дефолтным поведением show.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Что-то в системных требованиях не было написано «Не использовать имя пользователя `Артур`», поэтому ожидаемо было отсутствие косяков.

aptyp ★★★★
()
Ответ на: комментарий от aptyp

Что-то в системных требованиях не было написано

Это подразумевается. Мы пока не заслужили уважительного отношения к русским именам/идентификаторам. Даже в юникодовской ипостаси.

Macil ★★★★★
()
Ответ на: комментарий от Pinkbyte

Ты дебил. Этот человек про ФП знает на порядок больше чем весь ЛОР, но при этом считает, что в индустрии ФП не место. Так кто там чего «не осилил»? Осиль сначала ФП на его уровне, а потом критикуй.

anonymous
()

как мне нравится слово bugfix-релиз ) ласкает слух

Bridgit
()
Ответ на: комментарий от anonymous

[..]но при этом считает, что в индустрии ФП не место.

Там нет таких слов.

dave ★★★★★
()
Ответ на: комментарий от buddhist

Конечно. Например, многообразие виндовых программ.

Аргумент неочевиден.

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

Если да, то это все равно что на утверждение «на машинах можно перевозить различные виды груза» парировать «например есть многообразие машин, что возят дрова».

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

Я не спорил с тем, что C переносим. Я спорил с тем, что его гегемония _гарантирует_, что он переносим, да еще и с точки зрения индустрии (то есть, должно быть некоторое множество переносимых либ и тулзов хорошего качества).

buddhist ★★★★★
()
Ответ на: комментарий от Bioreactor

А нормальные люди могут прочитать

Статью 1998 года с посылом «пора делать реализации ФП с прицелом на практическое использование, а не на прототипирование идей».

Вот интервью этого года - http://www.infoq.com/interviews/wadler-functional-programming. В котором упоминаются такие реализации (Haskell, Erlang, Scala, F#).

quasimoto ★★★★
()
Ответ на: комментарий от buddhist

Переносимость — она не в языке, она в головах, а C слишком системно-гибкий язык, чтобы насильно навязать переносимость.

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

Кстати, можете привести пример по-настоящему «переносимого языка»?

rtvd ★★★★★
()
Ответ на: комментарий от buddhist

Я не спорил с тем, что C переносим. Я спорил с тем, что его гегемония _гарантирует_, что он переносим, да еще и с точки зрения индустрии (то есть, должно быть некоторое множество переносимых либ и тулзов хорошего качества).

Естественно гарантирует. В том смысле, что по крайней мере компилятор есть почти подо все платформы и код, не зависящий от платформо-зависимых библиотек они должны собирать. А кросплатформенные библиотеки - дело второе. К тому же, кое-что есть. Всякие там cos, sprintf и прочее есть (почти) везде. А где их нет, то там и не будут пускать софт, что на них завязан.

rtvd ★★★★★
()
Ответ на: комментарий от science

и да чтобы прояснить, моих там чуть-чуть, я в haskell-team недавно.

qnikst ★★★★★
()
Ответ на: комментарий от anonymous

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

P.S. И да, то, что ты не умеешь мыслить шире, вовсе не дает тебе права обзывать собеседника «дебилом», даже если это ЛОР. На этом дискуссию полагаю законченной, ибо говорить с таким некультурным собеседником мне как минимум неприятно, независимо от твоей аргументации

Pinkbyte ★★★★★
()
Ответ на: комментарий от qnikst

статья 98 годов, половина аргументов _уже_ потеряли силу.

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

Не то чтобы их не было тогда... Но на фоне той вакханалии конца 90-х, когда цветастая VS 6.0 на новой и улучшенной Win98 казалась вершной прогресса... Нда. Тогда никто не думал, что закон Мура пойдет не «вглубь», а «вширь», что на винду будут накладывать по 6000 патчей и что даже прикладной софт будет высококонкурентым.

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

Чистое и ленивое ФП еще долго останется маргниалом. Не потому что плохо, а потому что концепции из императивного мира на нее непереносимы. А значит, аргументы приведенные по ссылке будут еще долго и долго доминировать в индустрии.

Но ведь это неплохо, правда?

Macil ★★★★★
()
Ответ на: комментарий от Macil

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

EvgenijM86
()
Ответ на: комментарий от EvgenijM86

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

dave ★★★★★
()
Ответ на: комментарий от dave

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

qnikst ★★★★★
()
Ответ на: комментарий от dave

с другой стороны ленивость мешает

если речь о паралеллизации, то вспоминать практически не приходится

jtootf ★★★★★
()
Ответ на: комментарий от Macil

из ФП вообще удастся сделать очередную серебряную пулю

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

jtootf ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.