Haskell Похоже, этап "Lazy Ωmega с Type : Type" (это ветка nokinds) решили пропустить и переходить сразу к Lazy Idris
ghc.haskell.org
Ну и правильно: чего тянуть-то?

Haskell Все, один из самых популярных вопросов про хаскель, а именно "почему у меня fold стек переполняет?" уходит в прошлое: ghc.haskell.org

ghc производительность C Intel Haskell leafpetersen.com

ghc Haskell Оказывается, ведутся работы по исправлению проблем с безопасностью GeneralizedNewtypeDeriving github.com И семи лет не прошло!

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

The GHC versions appear too fast (last 13 years). If asked, I would ask to make them to appear 5 times slower.

например? Если бы так было в действительности — ghc-хаскель был бы все еще унылым компилятором унылого ML++ (ну это ладно, на любителя), так еще и без нормальных строк, массивов, GC, без SMP, поддержки юникода, без репл, вообще без всего и с производительностью генерируемого кода в 10-100 раз меньше чем сейчас. Ну, о чем еще мечтать-то?
Или вот:

If you want GHC to compete with GCC or Clang, then you know what

to do: stop experimenting with the language.

Наверное, уменьшение экспериментирования с языком здорово помогло mlton, clean и, в меньшей степени, ocamlopt потягаться c gcc и clang? Нет, не помогло? На самом деле mlton, clean и, в меньшей степени, ocamlopt умерли? Ну что же, слишком быстрого развития за последние 13 лет уже не поправить, а добавить в список мертвечины ghc вполне еще можно, если хорошо стараться.

Haskell

Во-первых расширения используются любые.

Да неужели? Много вы видели кода с использованием неявных параметров, например?

давайте тогда стандарт менять, а не расширять его каждые два месяца.

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

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

Потому, что книги консервативны в принципе и книгоиздательский процесс не справляется со скоростью развития языка и библиотек (тот же RWH сейчас полезен, как отрывной календарь 2008-го года.). Именно поэтому и существуют Бесполезные Хаскели 98 и 2010 — чтоб можно было написать книгу, примеры из которой будут компелироваться. Другого предназначения у этих "языков" и нет.
> В-четвёртых то как сейчас написана haskell platform заранее ставит крест на любой альтернативной реализации языка
Проблема тут вовсе не в расширениях, а в том, что написать компилятор хаскеля — нетривиальная задача требующая многих человеколет. Что характерно, ни одного нормального компилятора кроме ghc и для haskell 98 не было написано: NHC и форки тормозные и мертвые (h98 с натяжкой поддерживают), а JHC и UHC не реализуют даже h98.

n+k Haskell А ведь n+k паттерны позволяют достаточно изящно записывать код обхода всяких контейнеров с доступом по индексу: gist.github.com Раньше я об этом как-то не задумывался. Сможет кто-нибудь это красивее написать?

ленивость fp Haskell ml gist.github.com

stream-fusion Vector Haskell gist.github.com

Linux VirtualBox Haskell Мне, последнее время, хочется организовать такую автоматизацию: появляется свежий ночной билд GHC haskell.org — скачивается, встраивается в максимально облегченный линукс (какой дистрибутив для этого лучше использовать? Как можно автоматизировать его модификацию?), в котором минимальное рабочее окружение для хаскеля (ghc, cabal, vim/emacs c haskell mode) и все это оформляется как образ для virtual box, например. Т.е. без всякой боли и ужаса — максимум одно нажатие — и ты в шаге от самого острия прогресса. Может у кого-нибудь есть соображения на этот счет? Как такое обычно организуется?

ghc Haskell Уже два человека запостили анонс, но ни один не удосужился дать ссылку на список нововведений. hackage.haskell.org

fsharp fsi Тут у гипотетического читателя прошлого поста, ошарашенного феноменальной полезностью файла Script.fsx, закономерно возникнет вопрос: получается, что можно открыть файл Script.fsx — и мы получим откртое окно интерпретатора, в который все нужное для работы уже подгружено. Ведь верно? Ведь правильно? Нет. Не верно. Скрипт отработает без вывода на экран и интерпретатор закроется. И это не шутка, как бы абсурдно это не звучало.

fsharp leksah vs Отдельная история — это "индеграция" fsi с VS. Даже в такой кривой поделке как leksah есть работающая команда в контекстном меню Eval. Интуитивно понятно, что она сделает: запустит интерпретатор, если он не запущен, загрузит модуль и все зависимости, если они еще не загружены и выполнит выделенный код. В "интеграции" F# c VS ничего такого не произойдет: программист должен страдать! Команда Send to Interactive — тут просто для галочки, не предполагается. что кто-то этим будет пользоваться — так что и команда делает буквально то, что написано: отправляет код в интепретатор и выводит ошибку. Это действие в F#, разумеется, вовсе не имеет смысла. Имело бы смысл отправлять в интерпретатор, по крайней мере, все файлы расположенные выше данного по порядку и ту часть открытого файла, что выше выделенного текста. Ха! Мечтайте больше. Вопиющая бессмысленность функции создателей "интеграции" не полнует. Но что это? При создании проекта в нем создается и файл Script.fsx. Может в него автоматически пишется загрузочный скрипт для проекта? Нет писать нужно вручную. Сидите и пишите:
#r "FSharp.PowerPack.dll"
#load "Fancy.fs"
open Henry.Every
open Fancy
#load "Revenge.fs"
open HMS
open Revenge
Ну, может, он хоть загружается автоматически или нажатием одной кнопки? Где-то такая кнопка может и есть, но из коробки все так: выделяете весь текст скрипта -> Send To Interactive!

fsharp ghci fsi Пока у меня складывается впечатление, что самые нижние этажи F#-ада, стигийские лиды — это REPL. Предположим, вы пишете в командной строке fsi Fancy.fs — ну понятно, Fancy.fs должен существовать. Если бы вместо fsi был ghci, а вместо fs был hs, мы бы получили открытое окно интерпретатора в котором загружен модуль, можно было бы что-то делать с объявленными в модуле и импортированными функциями, конструкторами и т.д. Но мы-то имеем дело с F# и тут ничего такого не получится по ряду причин. Во-первых, не знаю как у вас, но у меня fsi при установке VS не прописался в путях, так что команда fsi просто не будет найдена. Ну это легко исправить. Дальше — хуже. Файл Fancy.fs не представляет из себя какой-то самодостаточной единицы — это просто один из кусков кода, которые нужно подгрузить в определенном порядке в духе суровых инклюдов. Ghci подгрузил бы установленные пакеты, от которых зависит открываемый файл, но fsi это делать не станет. Да, FSharp.PowerPack в Assembly Cache — ну так что с того? Давайте, не ленитесь, ручками, ручками — #r "FSharp.PowerPack.dll";; Автоматика, модульность — это все зло и грех, все необходимо отсечь: программист на F# должен знать только келью, духовника и все!

fsharp pastebin Пастебины люто ненавидят F#. Всем своим пехепешным сердцем. Если пройтись по списку пастебинов из википедии окажется, что поддерживают подсветку кода на нем только pastebin.com и pzt.me, ну это если нет желания пользоваться каким-нибудь голландскоязычным plakkert.nl. При этом в списке языков вполне может оказаться какой-нибудь ioke, но F# там не будет. Возможно это связано с тем, что все думают, будто бы F# — это такой окамл и можно пользоваться окамловой подстветкой. Косвенно это подтверждается тем, что gist.github позволяет выбрать F# в списке, но подстветку использует от окамла — т.е. минимальное требование — визуальное отличие кода от комментариев не выполняется. // комментарии как комментарии не распознаются.

Juick Но самое удобное, конечно, это то, что уже больше двух недель прошло с момента регистрации, а оставлять комментарии я все еще не могу. "Sorry, you can't reply to this post." отвечает Жуик. Но почему так происходит нигде не написано. Точнее, можно нагуглить пост в котором упоминается, что новые пользователи попадают в "песочницу". Но на какой срок? На полгода, год, навсегда? И что нужно сделать, чтоб получить возможность комментировать? Приобрести малиновые штаны? Визатор должен определять меня как чатланина?

fsharp Haskell Раньше мне казалось, что вокруг f# существует какой-никакой но хайп, есть многочисленное коммьюнити, поддержка МЕГАКОРПОРАЦИИ и все такое. На практике же оказалось, что F# — язык эзотерический. Посудите сами, на stackoverflow тегом f# помечено 2256 вопросов. Для сравнения: haskell 3123, хотя по сравнению с ocaml (494) и sml (176) популярность просто бешеная. Каждую неделю задается сопоставимое (общему количеству вопросов про F#) число вопросов по "языкам программирования" C# и Java. Субреддит /r/fsharp читают 611 человек (/r/haskell 6948), свежайшая новость там запощена 12 дней назад. О существовании F# даже в МЕГАКОРПОРАЦИИ многие не подозревают, например, на codeplex нет подсветки кода для F#. На GitHub и BitBucket ее, разумеется, тоже нет. О чем говорить? На гитхабе F# (37-е место по популярности) нет в выпадающем списке языков в поиске (хаскель там в блоке "популярные", 15-е место).

Тэги, оказывается, не распознаются в тексте сообщения, их нужно все перечислять в начале. Это, просто ПОТРЯСАЮЩЕ УДОБНО. Уверен, что каждый мечтал о такой возможности.

fsharp csharp Agda ml Земную жизнь пройдя до середины, я очутился в жизненной ситуации, которая заставляет меня изучить *fsharp. Это, конечно, полуправда. Никто заставлять изучать F# не станет, но если можно писать на работе на нем, а не на *csharp — то почему бы и нет? Уж если приходится есть пирожки с булавками — пусть они будут хотя бы английскими. Не пирожки, а булавки, конечно. Такой оптимизм основан на том, что я поверхностно знаком с "функциональными языками" *ml семейства и примерно представляю, чего от них ожидать. Чтоб смыть железное послевкусие булавок, я параллельно продегустирую что-нибудь заведомо приятное, *agda 2, например.

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