GHC 8.2.1

Stable release
14.01.1 / September 8, 2014; 2 years ago

Мда.
upd: Ан нет, пилят таки: http://www.mercurylang.org/news.html

Даже SWI-Prolog живее.

https://github.com/Mercury-Language/mercury

Latest commit 05433e8 21 minutes ago

Надеюсь теперь оно будет лучше компилировать Idris.

На какой, мне интересно. Из современного я только core.logic у Clojure вспомнить смогу.

В LispWorks есть модуль такой: http://www.lispworks.com/products/knowledgeworks.html

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

На какой, мне интересно.

Я в одной такой вакансии видел Python.

Крайне сомнительно. Ты говоришь о бизнесе, мэйнстриме, но как раз он и не любит языки, в коотрых разбирается пара десятков яйцеголовых на всю страну. Да и откровенно, НЕТ ничего в Хаскеле, чего нельзя было бы написать на C# (пусть ценой раздутия кода).
Точнее, тут так: C# достаточно универсальный язык, на котором можно решить любую задачу. Поэтому преимущество Хаскеля именно как «решателя конкретной проблемы» - нулевое. А вот в плане сопровождаемости и заменяемости программистов, C# ещё даст фору!

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

НЕТ ничего в Хаскеле, чего нельзя было бы написать на C#

Нет ничего в C#, чего нельзя было бы написать на С.
Нет ничего в C, чего нельзя было бы написать на ASM.
Нет ничего... ну ты понял.

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

Да и откровенно, НЕТ ничего в Хаскеле, чего нельзя было бы написать на C#

Можно и из хлеба сделать троллейбус, но зачем?

Кто тут в теме есть, скажите пожалуйста, у хаскеля есть какие-нибудь актуальные компиляторы кроме GHC? cast qnikst.

Стандартная библиотека уже стала потокобезопасной?

НЕТ ничего в Хаскеле, чего нельзя было бы написать на C#

Тут вопрос стиля мышления. Если кодишь что-то из математической логики удобнее изъяснятся на функциональном языке. Оно то можно конечно сделать interface Term { bool eval(); } class Conjuction: Term { ... }, но приятного в таком коде мало, особенно учитывая, что мозги не успевают перестраиваться с «Терм это переменная или конъюнкция термов» на классы когда регулярно поглядываешь в книжку.

у хаскеля есть какие-нибудь актуальные компиляторы кроме GHC?

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

Сейчас стараются широко использовать GHC, например, даже для генерации JavaScript (ghcjs) и генерации байт-кода Java (eta-lang)

объективно нету, jhc для встраиваемых как-то шевелится, но далеко не все соберёт.

но далеко не все соберёт

Вся кабала пакетов чисто под ghc. Впрочем встречаются древние поделия под иные компиллеры, но их еще попробуй скачай (сайты давно сдохли).

нет, но да.

Конечно будет. И пюреха будет скорее собираться, дабл профит.

Был еще норм ajhc, но авторы на него забили и слили с jhc.

Кстати, зря про анбоксед суммы не упомянули. Раз тут собрались эксперты, вопрос: в каком состоянии форк ghc от tweag.io?

Работа то linear types ведётся, можно для простоты брать докер образ и экспериментировать, но работы там ещё уйма. Поидее даже proposal вместе с SPJ не написали, т.к. там есть инетересные вопросы, которые нужно дорешать. Но уже компиляет и что-то делать можно.

Кстати, зря про анбоксед суммы не упомянули

Я много чего не упомянул. Допиливание OverloadedRecordFields, например.

НЕТ ничего в Хаскеле, чего нельзя было бы написать на C#

что такого можно написать на этом вашем С#, что нельзя написать на COBOL?

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

Стандартная библиотека уже стала потокобезопасной?

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

Потокобезопасность = тормоза в одном потоке.

Нет.

Нужно писать многопоточно - узай специализированные контейнеры.

Без комментариев.

Да и мутексы никто не отменял.

Без комментариев.

до раста.

В Rust нет и не предвидится green threads.

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

Не особо впечатляют кого?

Message passing дает гораздо больше, нежели простая иммутабельность данных.

Ты про Cloud Haskell слышал?

вот среди хаскелистов физиков, кстати очень много.

green threads.

Они то тут причем? С ними то и проблем никаких нет кроме того, что они на одном ядре живут.

С ними то и проблем никаких нет кроме того, что они на одном ядре живут.

Где? Haskell/Java/.net/Erlang они мапятся на множество системных тредов.

мапятся на множество системных тредов.

Тогда это уже не совсем green, а комбинация с native. Кстати вкусная фича, жалко что кроме тормозного ерланга ни одной популярной платформы с поддержкой такой штуки нет. Ну в смысле с message passing..

Это самый что не на есть green. m:n который.

Тогда это уже не совсем green, а комбинация с native.

Это совсем green, зеленее некуда просто.

Кстати вкусная фича, жалко что кроме тормозного ерланга ни одной популярной платформы с поддержкой такой штуки нет. Ну в смысле с message passing..

Ты, кажется, нифига не знаешь о том, почему в Erlang сделана передача сообщений и убрана возможность шарить данные между тредами. В Erlang у каждого треда своя куча, и, соответственно, GC не требуется останавливать весь мир во время сборки мусора, как это сделано во всех других языках с GC. Минусом этого подхода является как раз необходимость кидать сообщения и копировать (да, я знаю, что там есть пара хаков) данные между тредами.

Алсо, Cloud Haskell и Akka.

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

О каких именно разработках речь?

По работе нам вроде хватает и фреймворков и библиотек, написать свой DSL в хаскеле - проще простого, и это делает всякий проект под свои задачи. Для веба посмотрите в сторону серванта http://haskell-servant.readthedocs.io/en/stable/ едва ли есть где-то что-то аналогичное, для этого как минимум должна быть настолько же мощная система типов.

Если green треды на разных ядрах, то шарить данные между ними физически опасно.

Если green треды на разных ядрах, то шарить данные между ними физически опасно.

Физически? Током долбанёт, что ли?

Если green треды на разных ядрах, то шарить данные между ними физически опасно.

физически опасно

Если такое происходит, мейнтейнерам GHC отсылается письмо и они ломают тебе ноги? Или что?

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

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

По каким таким физическим причинам? Что ты вообще несёшь? И что ты имеешь ввиду под «одновременной» записью?

Скорее всего он имеет ввиду это:

import Control.Concurrent.Async
import Control.Monad
import Data.IORef
main = do
  foo <- newIORef 0
  let worker = replicateM_ 1000 $ modifyIORef foo (+1)
  _ <- concurrently worker worker
  print =<< readIORef foo

qnikst@qwork ~ $ ghc -threaded 1.hs
[1 of 1] Compiling Main             ( 1.hs, 1.o )
Linking 1 ...
qnikst@qwork ~ $ ./1
2000
qnikst@qwork ~ $ ./1 +RTS -N
1328

но объяснять почему это не причина и все в прядке даже не хочется.

Это не физическая причина, это тупо race condition.

делай скидку на то, с кем разговариваешь :]

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

Правда тут пофиг грин треды или не грин

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

modifyIORef

это вам не mov [ax], bx. Там защита стоит, потому и работает.

ващет если внимательно посмотреть на выхлоп - то не работает, а работает atomicallyModifyIORef которое добавляет memory barriers.

Ну оно int. Я просто надеялся что оно выливается в atomic, просто (+1) не распарсился в atomic_increment

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

Сфига ли? Это был бы жирный баг в процессоре. В однопроцессорных системах один контроллер памяти вне зависимости от количества ядер, а в многопроцессорных от этого NUMA защищает.

Но если у тебя есть тест, было бы интересно это увидеть.

Там защита стоит, потому и работает.

Защита чего от чего?

Я просто надеялся что оно выливается в atomic, просто (+1) не распарсился в atomic_increment

Потому что atomic — это медленно.

сходу не найду но или в what every programmer should know about memory или в is parallel programming hard and what we could do about it, пример с диаграммами был.

сходу не найду но или в what every programmer should know about memory или в is parallel programming hard and what we could do about it, пример с диаграммами был.

В первой вроде не было. Если найдёшь, ткни меня.