http://lambda-the-ultimate.org/node/3319#comment-48760
On the Logical Basis of Evaluation Order and Pattern Matching
...the answer to the question of eager vs. lazy evaluation is encoded in types, rather than being a global property of the language.
А действительно, почему бы и нет? Эффекты-то типами отделяют, так и с порядком вычислений можно сделать.
Здравствуйте, thesz, Вы писали:
T>http://lambda-the-ultimate.org/node/3319#comment-48760
T>On the Logical Basis of Evaluation Order and Pattern Matching
T>...the answer to the question of eager vs. lazy evaluation is encoded in types, rather than being a global property of the language.
T>А действительно, почему бы и нет? Эффекты-то типами отделяют, так и с порядком вычислений можно сделать.
Наличие чего-либо — в данном случае — контроля за lazy/strict на уровне типов — как правило лучше отсутствия.
Но все-таки интересно было бы поглядеть на то, как это реализовано, что называется — подержать в руках.
T>>http://lambda-the-ultimate.org/node/3319#comment-48760
T>>On the Logical Basis of Evaluation Order and Pattern Matching
T>>...the answer to the question of eager vs. lazy evaluation is encoded in types, rather than being a global property of the language.
T>>А действительно, почему бы и нет? Эффекты-то типами отделяют, так и с порядком вычислений можно сделать.
MC>Наличие чего-либо — в данном случае — контроля за lazy/strict на уровне типов — как правило лучше отсутствия. Но все-таки интересно было бы поглядеть на то, как это реализовано, что называется — подержать в руках.
Получится использование fmap вместо map, mplus вместо ++ и прочее.
Потребуется писать более обобщённый код. И обычный список, и строгий будут реализовывать все интерфейсы, что необходимы для быстрой смены кода.
Собственно, всё.
Жизнь, конечно, немного усложнится, как всегда при наличии выбора.
thesz,
T>А действительно, почему бы и нет? Эффекты-то типами отделяют, так и с порядком вычислений можно сделать.
Прикольно. Но неужели не боян? Фанки fun () -> ... можно использовать в любом ФЯ, а если же у него статическая типизация (Ocaml, Scala etc.), соответственно и разные типы (в случае Скалы List[Int] vs Stream[Int], в Окамл всякие lazy_t и unit->('a * 'a xxx)).
Вот проведение различий между <a,b>, (a,b) и a->b — это мне нравится, теоретически (
) haskell таким образом может стать быстрее C.
T>>А действительно, почему бы и нет? Эффекты-то типами отделяют, так и с порядком вычислений можно сделать.
LCR>Прикольно. Но неужели не боян? Фанки fun () -> ... можно использовать в любом ФЯ, а если же у него статическая типизация (Ocaml, Scala etc.), соответственно и разные типы (в случае Скалы List[Int] vs Stream[Int], в Окамл всякие lazy_t и unit->('a * 'a xxx)).
Ну, там это поставлено на прочную теоретическую основу.
Что идея витала в воздухе, совершенно согласен.
LCR>Вот проведение различий между <a,b>, (a,b) и a->b — это мне нравится, теоретически ( ) haskell таким образом может стать быстрее C.
А он и
бывает.