Женя,
E>Провожу тут для себя одно изыскание по языкам программирования и обнаружил интересный факт: оказывается, в языке Simula уже была такая штука, как Call by name. С помощью которой приведенный выше код unless мог быть написан и в чисто императивной Simula.
Проблема в том, что call-by-name в оригинальном виде совершенно непригодно к использованию. На практике это эмулируется стратегией call-by-need, что очевидно влечёт непредсказуемый результат в общем случае в условиях побочных эффектов.
Практически, однако, вопрос о соотношении 1) дефолтной ленивости с опциональной энергичностью и анализатором энергичности (strictness analyser) как в Хаскелле, и 2) дефолтной энергичностью с опциональной ленивостью (как в Ocaml, Scala, N, etc)
остаётся открытым и требует особого обсуждения.
LCR>На практике это эмулируется стратегией call-by-need, что очевидно влечёт непредсказуемый результат в общем случае в условиях побочных эффектов.
Да, забыл сказать, что Хаскелл определяется не как lazy язык, а как non-strict язык. Из-за этого возникают определённые терминологические флуктуации, откуда возникает путаница.
From what I understand, non-strict semantics are (very informally) about choosing an order of evaluation that, where possible, avoids non-termination or error. Laziness is about evaluating only what's needed.
In any case, I think all of the mainstream Haskell compilers and interpreters implement the non-strict semantics by means of lazy evaluation, so unless you're working on a radical new Haskell implementation, you probably don't need to worry about the difference.
То есть в принципе, call-by-need, non-strict и lazy не одно и то же, но разница с точки зрения практики столь незначительна, что можно не принимать во внимание.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Практически, однако, вопрос о соотношении LCR>1) дефолтной ленивости с опциональной энергичностью и анализатором энергичности (strictness analyser) как в Хаскелле, и LCR>2) дефолтной энергичностью с опциональной ленивостью (как в Ocaml, Scala, N, etc) LCR>остаётся открытым и требует особого обсуждения.
На сегодня я голосую за второй пункт, так как технологии оптимизации не дошли до того состояния чтобы обеспечить приемлемую производительность линивого кода. Умолчальная неленивость в сочетании с опциональной ленивостью позволяет решать все вопросы с приемлемым качеством и одновремнно обеспечивает удобство.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
LCR>>Практически, однако, вопрос о соотношении LCR>>1) дефолтной ленивости с опциональной энергичностью и анализатором энергичности (strictness analyser) как в Хаскелле, и LCR>>2) дефолтной энергичностью с опциональной ленивостью (как в Ocaml, Scala, N, etc) LCR>>остаётся открытым и требует особого обсуждения.
VD>На сегодня я голосую за второй пункт, так как технологии оптимизации не дошли до того состояния чтобы обеспечить приемлемую производительность линивого кода. Умолчальная неленивость в сочетании с опциональной ленивостью позволяет решать все вопросы с приемлемым качеством и одновремнно обеспечивает удобство.
скажем так — для высокоуровневой записи алгоритмов удобней первое, для скорости лучше второе. синтаксический оверхед для записи ленивых выражений в strict языке и наоборот можно сделать минимальным
далее идёт такое соображение — как минимум 80% кода программы вообще не требует оптимизации, для многих программ оптимизация не нужна вообще
а вообще, strict (или по крайней мере eager) реализация(и) хаскела существует. у меня даже была идея препроцессора, который "стриктизирует" хаскел код, скажем из такого:
fac 0 = 1
fac n = n*fac(n-1)
делает такой:
fac !0 = 1
fac !n = let t = fac $! (n-1)
in t `seq` n*t
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а вообще, strict (или по крайней мере eager) реализация(и) хаскела существует. у меня даже была идея препроцессора, который "стриктизирует" хаскел код
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>а вообще, strict (или по крайней мере eager) реализация(и) хаскела существует. у меня даже была идея препроцессора, который "стриктизирует" хаскел код
L>Библиотечные то функции он не стриктанёт
Здравствуйте, BulatZiganshin, Вы писали:
BZ>далее идёт такое соображение — как минимум 80% кода программы вообще не требует оптимизации, для многих программ оптимизация не нужна вообще
99% кода не требуют ленивосити, а замедление просходит всгда.
К тому же твои 80% высасаны из пальца. Мои задачи все идут на пределе современного железа. И линшей скорости у меня нет. Поэтому Хаскель для меня не приемлем в принципе. Я не готов отказаться от более сложных задач только ради мнимых приемуществ ленивости.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>далее идёт такое соображение — как минимум 80% кода программы вообще не требует оптимизации, для многих программ оптимизация не нужна вообще
VD>99% кода не требуют ленивосити, а замедление просходит всгда.
вот не сказал бы. в хаскеле даже чтение входного потока ленивое. так что тут дело в перестройке мышления, перестроишь — и у тебя неленивые алгоритмы будут получаться лишь с большим напрягом помнишь, я даже 5-ти строчную программу сделал эффектвиныей с помощью лени?
VD>К тому же твои 80% высасаны из пальца. Мои задачи все идут на пределе современного железа. И линшей скорости у меня нет. Поэтому Хаскель для меня не приемлем в принципе. Я не готов отказаться от более сложных задач только ради мнимых приемуществ ленивости.
уверяю тебя, что не меньше 80% кода в твоих задачах вообще не сказывается на конечной проивзодительности продукта. это я в общем-то нижнюю границу назвал. ну и твои задачи на работе могут быть весьтма специфичными, в общем и целом на первом месте функциональность и надёжность. скажем, в твоих rsdn'овских продуктах ни о каких "на пределе железа" речи быть не может
Lazy Cjow Rhrr wrote: > > Практически, однако, вопрос о соотношении > /1)/ дефолтной ленивости с опциональной энергичностью и анализатором > энергичности (strictness analyser) как в Хаскелле, и > /2)/ дефолтной энергичностью с опциональной ленивостью (как в Ocaml, > Scala, N, etc) > остаётся открытым и требует особого обсуждения. > > Лучше завести новый топик.
Хоть ты и не спрашивал, но народ начал голосовать, потому мои 5 копеек:
лично я больше игрался с Окамлом, чем с Хаскеллом. Так вот,
необходимость большинство функций работы со списками делать
хвостато-рекурсивными (делать внутренний цикл с аккумулятором, а при
возврате значения разворачивать список) — напрягает. Выбирать между map
и rev_map напрягает. Знать заранее, много ли получится элементов в
списке (и выбирать между энергичным списком и ленивым потоком) —
напрягает. Разные fold'ы и map'ы для потоков и списков — некошерно. Вот.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>вот не сказал бы. в хаскеле даже чтение входного потока ленивое.
Оно везде ленивое. Ну, и что? А вся обработка не ленивая. И ленивость достигается банальными средствами вроде итераторов или просто вызовом функции вадающей за раз по символу/строке.
BZ> так что тут дело в перестройке мышления, перестроишь — и у тебя неленивые алгоритмы будут получаться лишь с большим напрягом помнишь, я даже 5-ти строчную программу сделал эффектвиныей с помощью лени?
Не помню. И не вижу тут ничего эффективного. Как не вижу необходимости перестраивать мышление. Я мыслю как мне удобнее. И задача инструмента обеспечить мне выражение моих мыслей в удобном мне виде.
VD>>К тому же твои 80% высасаны из пальца. Мои задачи все идут на пределе современного железа. И линшей скорости у меня нет. Поэтому Хаскель для меня не приемлем в принципе. Я не готов отказаться от более сложных задач только ради мнимых приемуществ ленивости.
BZ>уверяю тебя, что не меньше 80% кода в твоих задачах вообще не сказывается на конечной проивзодительности продукта.
Уверяю тебя, что лучше тебя знаю где мне требуется производительность, а где нет. Я в этом вопросе уже свору собак съел.
Тебе же я это сказал, чтобы ты не говорил за всех.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Практически, однако, вопрос о соотношении LCR>1) дефолтной ленивости с опциональной энергичностью и анализатором энергичности (strictness analyser) как в Хаскелле, и LCR>2) дефолтной энергичностью с опциональной ленивостью (как в Ocaml, Scala, N, etc) LCR>остаётся открытым и требует особого обсуждения.
Здравствуйте, AndreiF, Вы писали:
AF>А в чем вообще преимущество ленивости?
В том, что упрощается программа. Нет необходимости проверять граничные значения. Например, чтобы получить N элементов какой-либо последовательности, мы в энергичном языке должны писать compute_x N и в compute_x проверять это N, тогда как в ленивом языке эти детали можно опустить. Так же это помогает в случае, когда размер необходимых данных заранее неизвестен.
let fib = 1:1: (zip_with (+) fib (head fib)) - lazy variant, infinite list of fib numbers
let fib n =
if n = 0 then [1]
else
let _fib_acc n l =
if n = 0 then l
else _fib_acc (n-1) (((head l) + (head (tail l))) :: l) in
_fib_acc (n-1) [1; 1];;
То же самое можно сделать в энергичном языке при помощи итераторов, которые фактически являются локальным применением ленивости. А в чем преимущество ленивости везде и в обязательном порядке?
Здравствуйте, AndreiF, Вы писали: AF>То же самое можно сделать в энергичном языке при помощи итераторов, которые фактически являются локальным применением ленивости. А в чем преимущество ленивости везде и в обязательном порядке?
Ваши итераторы — суть костыли, писанина лишняя все равно нужна. Я же сказал, вообще, если отлечься от проблем с вводом-выводом, ленивые языки позволяют писать более простые программы за счет семантического упрощения (не надо обрубать концы цепочек вычисления вручную) + легко создавать бесконечные структуры данных.
Здравствуйте, Quintanar, Вы писали:
Q>Ваши итераторы — суть костыли, писанина лишняя все равно нужна.
Какая еще писанина? В C#, например, всё делается очень просто и ненапряжно.
Q> Я же сказал, вообще, если отлечься от проблем с вводом-выводом, ленивые языки позволяют писать более простые программы за счет семантического упрощения (не надо обрубать концы цепочек вычисления вручную) + легко создавать бесконечные структуры данных.
Локальное применение ленивости позволяет делать то же самое, только без необходимости упражнять свою силу воли, пытаясь отвлечься от проблем с вводом-выводом, предсказуемостью производительности и отладкой.
Здравствуйте, AndreiF, Вы писали:
Q>>Ваши итераторы — суть костыли, писанина лишняя все равно нужна.
AF>Какая еще писанина? В C#, например, всё делается очень просто и ненапряжно.
Может быть. Можно посмотреть реализацию ленивого map'а для ленивого списка?
Q>> Я же сказал, вообще, если отлечься от проблем с вводом-выводом, ленивые языки позволяют писать более простые программы за счет семантического упрощения (не надо обрубать концы цепочек вычисления вручную) + легко создавать бесконечные структуры данных.
AF>Локальное применение ленивости позволяет делать то же самое, только без необходимости упражнять свою силу воли, пытаясь отвлечься от проблем с вводом-выводом, предсказуемостью производительности и отладкой.
Шкала ценностей у всех разная. Для кого то получаемые преимущества перекрывают все недостатки с лихвой.
Здравствуйте, AndreiF, Вы писали:
Q>>Ваши итераторы — суть костыли, писанина лишняя все равно нужна.
AF>Какая еще писанина? В C#, например, всё делается очень просто и ненапряжно.
Но согласись, что любая ненулевая писанина — это больше и сложнее, чем нулевая
Q>> Я же сказал, вообще, если отлечься от проблем с вводом-выводом, ленивые языки позволяют писать более простые программы за счет семантического упрощения (не надо обрубать концы цепочек вычисления вручную) + легко создавать бесконечные структуры данных.
AF>Локальное применение ленивости позволяет делать то же самое, только без необходимости упражнять свою силу воли, пытаясь отвлечься от проблем с вводом-выводом, предсказуемостью производительности и отладкой.
В caml ленивые данные имеют особый тип, и это правильно.
Но это значит, что
1) Хиндли-милнеровский полиморфизм уже не прокатит (прокатила бы перегрузка и шаблоны в стиле С++), придётся писать клоны функций над ленивыми аргументами. Например, продублировать всю коллекцию функций обработки списков.
2) Появляются новые виды списков
— фиксированный список фиксированных элементов
— фиксированный список ленивых элементов (т.е. ленивая голова cons-пары)
— ленивый список фиксированных элементов (т.е. ленивый хвост cons-пары)
— ленивый список ленивых элементов (ленивы и голова, и хвост)
Для первого или последнего в языках предусмотрен списочный (или, хотя бы, инфиксный) синтаксис, т.е. [a,b,c] или a:b:c:[]
вместо префиксного Cons a (Cons b (Cons c Nil)))
Для третьего — увы, увы.
3) Сопоставление с образцом перестаёт быть прозрачным.
Ну ладно, фиг с синтаксисом. Ради локального применения можно и потерпеть, тем более, что вряд ли кто будет писать длинные ленивые списки.
Но вот загромождение библиотеки стандартных алгоритмов не радует.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Перекуём баги на фичи!
