Чтобы добавлять сообщения и комментарии, .

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

leafpetersen.com

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

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

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 whatto do: stop experimenting with the language.

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

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

gist.github.com

@klapaucius:
klapaucius

gist.github.com

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

Отдельная история — это "индеграция" 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!

@klapaucius:
klapaucius

Пока у меня складывается впечатление, что самые нижние этажи 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# должен знать только келью, духовника и все!

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

Раньше мне казалось, что вокруг 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-е место).

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

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

@klapaucius:
klapaucius

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