Вышел UHC 1.0.0

>Ленивость это еще ерунда, меня просто шокирует, что он сам типы умеет выводить в очень сложных выражениях.

А собсно что тут непонятного?

>По-моей грубой оценке в яве, питоне и эрланге их в 5-10 раз меньше

ну не надо откровенную чушь всё-таки писать, ну?

не нужен.

питон уже написан.

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

Есть. Конкретно -- программа может жрать в 100 раз больше памяти, чем это ей реально надо. Приготовься брать в руки профайлер и ...

<...> Runciman and Wakeling reduced the peak space requirements of a clausification program for propositional logic by two orders of magnitude, from 1.3 megabytes to only 10K (Runciman and Wakeling, 1993). Runciman and Wakeling’s original profiler <...>

Being Lazy With Class -- там много интересного есть.

>Что это значит и насколько это больно? :)

В мозгу болевых рецепторов нет. Так что не больно.

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

С ленивостью, это все фигня. Самые большие грабли с монадой IO, главным образом с комбинированием с отстальными монадами.

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

К сожалению, "обычные" идиомы программирования в хаскеле бесполезны, даже вредны. Даже не пытайся найти какие-то аналогии со структурным или объектно-ориентированном программированием.

> К сожалению, "обычные" идиомы программирования в хаскеле бесполезны, даже вредны. Даже не пытайся найти какие-то аналогии со структурным или объектно-ориентированном программированием.

Вот-вот. И еще не понятно, стоит ли профит человеко-часов, угробленных на все это. Я больше с окамлом играюсь, ближе он как-то к "народу", в меру и функциональщина, и императивщина. Прост и понятен. Опять же, на практике его применить полегче. Ну это мое личное мнение, конечно.

> К сожалению, "обычные" идиомы программирования в хаскеле бесполезны, даже вредны. Даже не пытайся найти какие-то аналогии со структурным или объектно-ориентированном программированием.

И какой смысл делать ЭТО руками? Писать надо по-старому, только аннотировать функции получше, чтобы компилятор умел

1. находить чистые функции

2. преобразовывать все мной написаной в функциональный код.

Система типов хаскеля мне нравится. Оголтелая функциональщина -- нет (пусть в нее преобразует компилятор, если в этом есть смысл). Ленивость -- должна быть не по умолчанию, а когда я попрошу.

>И еще не понятно, стоит ли профит человеко-часов, угробленных на все это.

Профит есть и очень большой. Начинаешь смотреть на многие вещи совсем под другим углом.

>Я больше с окамлом играюсь,

Да в принципе, то же самое. Мне он не нравится из-за обилия синтаксического сахара.

Хаскль очень хорошо подходит для прототипирования. Плюс поддержка функционального кода, как это не странно звучит, осуществляется намного легче.

>только аннотировать функции получше, чтобы компилятор умел

Не, лучше не так. Во-первых оставим функциональщину, ибо она не главное. Лучше рассматривать в свете императивный-декларативный.

1. Мы создаем некое декларативное определение в каких-то (совешенно не важно каких именно терминах). Например: "хочу чучу".

2. У нас есть набор правил, который позволяет создавать из декларативного описания императивное.

3. У нас есть интерпритатор, который преобразует императивное описание в целевой код.

4. Можно грабить корованы.

> Не, лучше не так. Во-первых оставим функциональщину, ибо она не главное. Лучше рассматривать в свете императивный-декларативный.

Декларативность большей частью окупаться не будет. Может только через несколько десятков лет?

Пример: надо попытаться разложить многочлен небольшой степени с целыми коэффициентами на множители (тоже с целыми коэффициентами). Рассмотрим такое имеративное решение (то, что есть другие решения, не предмет разговора):

1. Найти комплексные корни (методом последовательных приближений) с некоторой точностью.

2. Перебрать все комбинации корней и посмотреть, не получаются ли целые числа.

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

________________________

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

>Мне стало интересно выяснить, где вообще декларативные подходы работают.

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

В числодробилках декларативность действительно не нужна... С другой стороны, если у тебя есть рекурсивный объект (факториал, ряд Фибоначчи, определитель матрицы), то почему бы их и не описать декларативно.

Кроме того, бери выше. Разве математические модели описываются императивно? Ну например, каноническая задача линейного программирования или модель межотраслевого баланса?

Можно услышать аргументы?
Мое мнение основано на недельном опыте знакомства с хаскелем. Возможно я считаю синтаксической конструкцией то, что ей не является. Хочу услышать опровержение от более знающих людей.
Давайте считать вместе.
Ява:
Объявление пакета, класса, интерфейса, перечисления (enum), метода, переменной, константы. Арифметические действия. if, case, while, for. Наследование, полиморфизм, 4 типа доступа для энкапсуляции. Статические методы. Абстрактные классы. Массивы, строки. Генерики. Внутренние классы (ака замыкания).
Все или я что-то забыл?
Многопоточность в синтаксис не включаю - все состоит из обычных методов и классов.
Итого 25 - 30.

Эрланг:
Объявление константы, именованой константы, атома, кортежа, списка, binary, функции, модуля, макроса. if, case. Паттерн матчинг, гварды. Списочные выражения (list comprehension). Внутренние функции (замыкания). Поведения (behaviors). Послать сообщение, получить сообщение.
Все? (здесь менее уверен в полноте списка, т.к. с эрлангом далеко не так хорошо знаком)
Итого 20-25.

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

Хаскелл:

объявление модуля, импорт модуля, определение функции, применение функции, объявление приоритета и ассоциативности оператора, определение синонима типа (type), определение типа-кортежа (newtype), определение АТД (data), определение класса типов, определение экземпляра класса, if, case, do, лямбда-выражение, list comprehension, сопоставление с образцом.

Итого: 15-20.

1.Монады (и всякие стрелки)
2. '' для создания инфиксных функций
3. $
4. if + do (я не осилил эту конструкцию :( )
5. _ (забыл перечислить ее в эрланге)
6. Макросы? (я не в курсе, входят ли они в сам язык)

>1.Монады (и всякие стрелки) 

не является конструкцией языка, класс типов Monad описан в Prelude.
имеется в виду do-синтаксис? ну тогда в любом императивном языке надо
считать все различные операции присваивания

>3. $ 

не является конструкцией языка

infixr 0  $

($)   :: (a -> b) -> a -> b
f $ x =  f x

>4. if + do (я не осилил эту конструкцию :( )

а это чего такое?

>6. Макросы? (я не в курсе, входят ли они в сам язык)

не входят

>класс типов Monad описан в Prelude.
>($)   :: (a -> b) -> a -> b
не знал.

>а это чего такое?
Внутри блока do зачем-то меняется конструкция if. Надо еще пару раз писать do и ставить хитрые отступы. На этом месте я сломался ).

http://en.wikibooks.org/wiki/Haskell/Indentation

Wrong 
if foo
    then do first thing
         second thing
         third thing
    else do something else

Right
if foo
    then do 
     first thing
     second thing
     third thing
    else do something else


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

Как насчет второй части моего утверждения:
"Легко писать код, который будет выглядеть бессмыслицей даже для опытных хаскелистов". 
Это ошибочная точка зрения?
 

> Например,описываем некую схему данных и хотим, чтобы она автоматически помещалась/извлекалась из БД,

Все это голимая императивщина. Например, мы описываем класс на яве, с помощью рефлексии (и возможно учитывая аннотации) генерим к нему таблицы БД, методы для записи/чтения из БД, ...

Это можно (и нужно) назвать метапрограммированием. Но никак не декларативностью.

Еще хуже с решением задачи линейного программирования -- тут вообще нет даже метапрограммирования (хотя если речь идет о задаче ЛП с несколькими нелинейными ограничениями, которые, предположим, меняют сам алгоритм -- тут может быть МП)

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

Настоящая декларативность -- это когда результат ее трансформации в императивный код НЕОДНОЗНАЧЕН и скорее всего допускает нетривиальные оптимизации, выполнение которых "напрямую руками" затруднительно, нечитабельно, легко может привести к ошибкам.

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

>Это ошибочная точка зрения?

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

есть сложности с чтением сильно point-free кода, но для него применимы правила чтения кода на J :) да и не так уж много хаскелистов в таком стиле пишут

>Надо еще пару раз писать do

в примере я этого не зматетил. где там лишние do?

>ставить хитрые отступы

emacs haskell-mode и leksah умеют это делать самостоятельно ;)

Возможность написать

f x:xs =

вместо

f y = ... тут делим на голову и хвост ...

конечно полензно и добавляет наглядности, но называть ли это декларативностью?

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

Вот пара примеров настоящей декларативности:

1. Пишем makefile на декларативном языке, а его интрепретатор уже сам решает, как его распараллелить, учитывая количество ядер процессора и замеры времени работы по прошлым запускам.

2. трансформация императивно-записанного-кода в функционально-записанный.

> единственный хаскельный код, который я видел и который был для меня (а я далеко не опытный хаскелист) совершенно нечитаемым - это результат генерации стрелочного кода в Yampa

И тут же встает вопрос -- чем этот нечитаемый код лучше императивного?

Его проще программно создавать? Программно модифицировать? Программно компилировать? Использовать в своих проектах?

> единственный хаскельный код

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

>Его проще программно создавать? Программно модифицировать? Программно компилировать? Использовать в своих проектах?

хм. ну, 3D-шутера уровня Quake 3 на императивном ЯП, BSP-код в котором занимал бы ~70Kb лично я не видел :) можно это считать аргументом?

>в примере я этого не зматетил. где там лишние do?

http://en.wikibooks.org/wiki/Haskell/Simple_input_and_output

 doGuessing num = do
       putStrLn "Enter your guess:"
       guess <- getLine
       if (read guess) < num
         then do putStrLn "Too low!"
                 doGuessing num
         else if (read guess) > num
                then do putStrLn "Too high!"
                        doGuessing num
                else do putStrLn "You Win!"

Вот здесь я не понимаю, почему недостаточно один раз написать do в начале функции. И еще я не понимаю, почему авторы учебника нарушают свои же правила отступа (отступы в этом примере соответстуют схеме, отмеченной как Wrong в разделе http://en.wikibooks.org/wiki/Haskell/Indentation).

>Я бы согласился называть это декларативностью, если бы туда (вместо двоеточия) можно было вставлять намного более сложные конструкции, чем просто конструкторы алгебраических типов данных

ну тогда идеальный декларативный ЯП для тебя - Рефал. там можно

>не понимаю, почему недостаточно один раз написать do в начале функции

ну сделай десахаризацию этого do и посмотри почему нельзя. do-нотация - это всего лишь другой способ записи комбинаторов >> и >>=, никакой магии он не совершает и совершать не умеет

>Это можно (и нужно) назвать метапрограммированием. Но никак не декларативностью

метапрограммирование - это способ повысить уровень декларативности кода, не? :)

> Плюс поддержка функционального кода, как это не странно звучит, осуществляется намного легче.

Осуществляется намного легче поддержка именно функционального кода или поддержка более абстрактного кода с проверкой компилятором обоснованности применения абстракций?

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

> 3D-шутера уровня Quake 3 на императивном ЯП, BSP-код в котором занимал бы ~70Kb лично я не видел :) можно это считать аргументом?

Можно, если нет никакого подвоха. Но он наверняка есть :)

> метапрограммирование - это способ повысить уровень декларативности кода, не? :)

Формально -- да. А фактически -- это примерно как сказать "костыли -- это способ повысить мобильность человека с переломом ноги".

т.е. до настоящей мобильности еще не дошло

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

> метапрограммирование - это способ повысить уровень декларативности кода, не? :)

класслоадер -- это тоже (попытка) повысить уровень декларативности кода,

так что различаем МП и ДП.

> хм. ну, 3D-шутера уровня Quake 3 на императивном ЯП, BSP-код в котором занимал бы ~70Kb лично я не видел :) можно это считать аргументом?

Я полагаю подвох там есть.

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

Я это имел в виду. Жду, кто меня разубедит.

Саныч, ну тебе-то не знать! Эпистрелку можно сокращать только с одной стороны, а изострелку с обоих. То-то.

> ну тогда идеальный декларативный ЯП для тебя - Рефал. там можно

щас глянул в википедии -- понравилось

надо попробовать поюзать рефал вместо перла.

>Я полагаю подвох там есть

ну поищи, исходники никто не скрывает

>функциональный подход и нечитабельный код необязательным побочным эффектом

что из этого является побочным эффектом? а необязательным побочным эффектом? :)

>класслоадер -- это тоже (попытка) повысить уровень декларативности кода

ммм...и что?

>> 3D-шутера уровня Quake 3 на императивном ЯП, BSP-код в котором занимал бы ~70Kb лично я не видел :) можно это считать аргументом?

> Можно, если нет никакого подвоха. Но он наверняка есть :)

Вот и подвох: "The test platform used in this benchmark is equipped with an Athlon XP 1900+ CPU, 512MB of DDR266 Ram and a Nvidia GeForce 4 MX 64MB" - выжало из себя 30-60 кадров/с. Вот еще один: "OpenGL drivers that support the vertex array and multitexture OpenGL extensions".

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

тебе дать ссылку на статью о взаимоисключающих параграфах?

декларативность достигается за счёт сложного устройства компилятора - чем больше компилятор может додумать сам, тем более декларативным будет твой код. как именно этого достичь - через метапрограммирование (т.е. беря на себя часть работы компилятора), или путём усложнения оного - неважно. у обоих методов свои pros and cons

>костыли -- это способ повысить мобильность человека с переломом ноги

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

> что из этого является побочным эффектом? а необязательным побочным эффектом? :)

Ладно, переформулирую попроще свою гипотезу. Но у меня сомнения, что ты поймешь. Однако, есть шанс, что другие поймут и ответят.

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

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

> ммм...и что?

некоторое повышение декларативности кода не делает язык декларативным, вот что.

>Вот и подвох

ну да, производительность там так себе. но никто не говорил, что там нечего оптимизировать :)

>Но у меня сомнения, что ты поймешь

ну у меня два варианта - либо я не понял, либо ты написал полнейшую ахинею

>хотели создать язык, оперирующий абстракциями

вот это, например, очень хорошо. скажи, а чем оперируют все остальные ЯП? :)

>они решили ограничиться чисто функциональным языком

они сами тебе это сказали? Пейтон-Джонс лично? :) не много ли ты за них говоришь, ну?

>Тем более, что простые случаи императивщины им удалось приемлево выразить в своем синтаксисе

ох. простые случаи императивщины - это очень круто. а что такое "сложные случаи императивщины"?

>И основной вопрос...

то есть ты предлагаешь писать императивно, но с аннотациями - чтобы компилятор преобразовывал всё это к функциональной записи? такой себе транслятор C** -> Haskell?

>некоторое повышение декларативности кода не делает язык декларативным, вот что.

а что делает? полное отсутствие возможности императивной записи?

> Можно, если нет никакого подвоха. Но он наверняка есть :)

Если вдруг какой-то язык с абстракциями ужал нормальный код в 2 раза, то вероятно он работает интерпретатором для самого себя. В этом будут только тормоза.

Смысл хорошего языка в легкости написании абстракций и затем в проверке их применимости компилятором. (Извращения с самоинтерпретацией нужны только для демонстрации мощи, но никак не для реальных 99% применений)

> вот это, например, очень хорошо. скажи, а чем оперируют все остальные ЯП? :)

похоже, мне надо прекратить свои попытки донести свой вопрос до тебя, или тебе попробовать все-таки меня понять

> то есть ты предлагаешь писать императивно, но с аннотациями - чтобы компилятор преобразовывал всё это к функциональной записи? такой себе транслятор C** -> Haskell?

преобразовывал всё это к функциональной записи *только если это действительно надо*, а если не надо -- оставлял во вполне императивном виде.

DDC сделал один шаг в правильную сторону, но полагаю надо гораздо больше:

For example, in Haskell the pure map function has type: map :: (a -> b) -> [a] -> [b]

but if we need to pass an effectful function defined in terms of a state monad, we must use the monadic version, mapM instead. mapM :: Monad m => (a -> m b) -> [a] -> m [b]

This puts us in a situation where we really need two copies of every higher-order function, one pure and one monadic. This is even more of a problem when a library (like Data.Map) exports a pure version but not a monadic one. In this case we either have to refactor our code to be less monadic, or spend time writing a function that should really be in the library.

>похоже, мне надо прекратить свои попытки донести свой вопрос до тебя, или тебе попробовать все-таки меня понять

достаточно написать proof of concept. язык, который будет реализовывать твой подход "императивного с аннотациями" - можно даже без компилятора, просто пример кода с пояснением

>преобразовывал всё это к функциональной записи *только если это действительно надо*, а если не надо -- оставлял во вполне императивном виде

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

>>некоторое повышение декларативности кода не делает язык декларативным, вот что.

> а что делает? полное отсутствие возможности императивной записи?

Ххx xxxxx xxxx xxxx xxxxxxx!

Ты безусловно очень интересный собеседник, но похоже ты не читаешь ВЕСЬ тред, и это меня совсем сбивает с толку.

вот слегка поредактировано http://www.linux.org.ru/jump-message.jsp?msgid=3646672&cid=3649952

Т.е. грань между ДекларативнымП и МП достаточно размытая.

Настоящая декларативность -- это когда результат трансформации декларативного кода в императивный код НЕОДНОЗНАЧЕН и скорее всего допускает нетривиальные оптимизации, выполнение которых "напрямую руками" затруднительно, нечитабельно, легко может привести к ошибкам.

____________________________

Понятно, что это еще и не полное определение.

>Если вдруг какой-то язык с абстракциями ужал нормальный код в 2 раза, то вероятно он работает интерпретатором для самого себя

вот как я после подобных должен серъёзно к тебе относиться и пытаться понять твои идеи?

что такое "язык с абстракциями"? а лучше что такое "язык без абстракций"? язык с фиксированным набором конструкций, не позволяющий себя расширять? язык разметки?

>вероятно он работает интерпретатором для самого себя

язык - это спецификация синтаксиса и семантики; интерпретатор - это вариант реализации языка. как язык может работать интерпретатором самомго себя? что за бред?