Хаскельное

[metaclass]

http://vit-r.livejournal.com/679524.html?thread=3691364#t3691364
решили на прошлой работе трое таки попробовать Хаскель, для неспешной задачи. генерация DDL, DML c скриптами SQL. Бились, бились, - но сделали, и был восторг! Потом, затянула обычная работа, через месяцок нужно было добавить кое-чего... и никто из троих не смог понять как оно работает, и как же добавить.

Звучит похоже на правду. Хотя у меня и F# и Clojure в подобных задачах живут и развиваются без проблем.

Comments

[thedeemon.livejournal.com]

>Статические анализаторы кода для Хаскеля есть?

Да, они там называются "компилятор".

[metaclass.livejournal.com]

50% же.

[thedeemon.livejournal.com]

Почему?
Первый тест заходит в строчки 1,2,4.
Второй - в 1,3.
Вместе покрывают все 1-4.

[rdia.livejournal.com]

> Да, они там называются "компилятор".

Т.е. нет. В отличие от компилятора, статический анализатор

1. не ограничен во времени => может проводить более глубокую проверку кода.

2. имеет право на ошибку - предупреждения статического анализатора любой степени серьёзности могут быть ложными.

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

let 2d_distance_from_origin {x : float; y : float; z : float} in
let x = p.x in
let y = p.z in
x^2 + x^2;;

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

И, хотя, Хаскел значительно лучше С, от подобных вещей он не защищает.

[rdia.livejournal.com]

> а доказательство, что в тестах проверятся каждая строка кода.

Т.е., действительно, как пишет тов. ниже, корреляции позволяется упустить?

[geniepro.livejournal.com]

Ну а сколько нужно?
В сях/сишарпе мне действительно часто приходится писать длинющие строки по 120 символов, но в хаскелле почему-то нет -- идентификаторы обычно короткие, так что сильно вправо код не лезет. Зато удобно два разных модуля на одном широкоформатном экране редактировать...

[geniepro.livejournal.com]

Был как-то тест, в котором в программы на разных языках вносили случайные опечатки, и смотрели, у кого компилятор больше таких ошибок обнаружит.
Хаскелл оказался защищён от таких ошибок гораздо хуже, чем с++ )))

[geniepro.livejournal.com]

Есть что-то типа того:

http://hackage.haskell.org/package/hlint

[thesz.livejournal.com]

data X
data Y
data Z

data Coord c a = C a -- c - phantom type, does not add runtime overhead.
instance Num a => Num (Coord c a) where ... -- you cannot add Coord X Float and Coord Y Float
type Vec a = (Coord X a, Coord Y a, Coord Z a)
field :: XYZ b => Vec a -> b -> Coord b a
field = ...

f p = let x = field p X; y = field p Z in x*x + castFromY (y*y) -- compiler error

[vit-r.livejournal.com]

Вот только это довольно бессмысленное занятие.

Для теоретика - да.

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

[vit-r.livejournal.com]

Не надо писать "выше-ниже" для дерева из сотни комментариев. При чём тут корреляции, я не понял. Это практическая методика, а не попытка доказать что-то статистикой.

[vit-r.livejournal.com]

идентификаторы обычно короткие,

Можно подумать, что это хорошо.

[rdia.livejournal.com]

Это, безусловно, классный приём, но что делать, если в 3-х местах не нужно складывать, а в 4-м нужно складывать координаты? Как норму считать - ещё пару вызовов вставить?

Подобную же штуку можно криво-косо сделать на С++, только овчинка выделки не стоит. Из-за раздутия кода вы сделаете ещё пару ошибок и т.д. Ухудшите ясность.

Я не спорю, что проверки в Хаскелле значительно круче, чем проверки в С++. Но в любом языке остаётся круг ошибок, которые не являются достойными занесения в компилятор, но вполне известны и часто повторяемы.

[thesz.livejournal.com]

Я потерял вашу мысль.

В Хаскеле я могу ограничить круг пропускаемых ошибок чрезвычайно малым числом. Библиотекой, не компилятором. Ну, и что, что в C++ так нельзя?

Насчет "как норму считать" - отдельной функцией, верифицированной. Как это делается в обычных библиотеках.

[geniepro.livejournal.com]

Идентификаторы не нужны сами по себе, и они должны отражать какую-то сущность. А в хаскелле чаще всего функции полиморфны, ну какие там сущности у их параметров? Имена вида x:xs достаточны в 80% случаев, имхо...

[vit-r.livejournal.com]

Я рад, что имена "ХЗ" достаточны для пишущих на Хаскеле. Я говорю про реальные задачи, где нужно писать что-то вроде "дополнительный коэффициент накопления поправки 1998 года"

[thesz.livejournal.com]

Кусок реальной программы:

-- | Вид блока памяти (для карты памяти)
data StoreKind addr where
    SKRegFile   :: StoreKind Int
    -- | Отображение внутренних переменных ядра в память (SPH, SPL, SREG)
    SKCPUVars   :: AVRCPU a =>
                   -- список переменных для отображения изменений в
                   -- отладочной печати (можно было бы и автоматом
                   -- извлекать из выражений)
                   [CPUVar (AVR a)] ->
                   StoreKind (AVRExpr a SIZE8, -- read expr
                              [Stat (AVR a)])  -- write stats
    SKSRAM      :: StoreKind Int
    SKFlash     :: StoreKind Int
    SKIO        :: StoreKind Int
    -- Внешняя память, с идентификатором
--    SKExternal  :: String -> StoreKind Int
    SKUndefined :: StoreKind ()

Есть ли вопросы?

[kurilka.livejournal.com]

А комментарии на английском и русском сразу не смущают?

[thesz.livejournal.com]

Я пишу на английском, коллеги пишут на русском. Что поделать. ;)

[thesz.livejournal.com]

Expression trees весьма ограниченный инструмент, хотя и полезность его нельзя отрицать. На одних expression trees я довольно быстро сваял подобие LINQ для некоей гиперграфовой БД (с преобразованием запросов а-ля LINQ в текст запросов к сей БД).

Если бы была возможность преобразовывать тела функций с циклами for и тому подобного, это был бы номер. Тогда можно было бы делать совершенно удивительные вещи, типа кода с циклами, компилирующегося в код над OpenCL. Или делать триггеры для тех же БД.

[jakobz.livejournal.com]

>возможность преобразовывать тела функций с циклами for и тому подобного
В F# есть такое: http://msdn.microsoft.com/en-us/library/dd233182.aspx

В C# есть надежда на "Roslyn" - они собираются выкатить API к компилятору, с возможностью использовать его куски, или втыкаться в середину: http://msdn.microsoft.com/en-us/vstudio/roslyn.aspx

[rdia.livejournal.com]

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

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

[thesz.livejournal.com]

Вы про зависимые типы слышали? Хаскель движется в ту сторону.

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

[vit-r.livejournal.com]

Ну и зачем начинать? Вопросы, естественно, есть. И они, естественно, не понравятся.

[thesz.livejournal.com]

Так задавайте.