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.

А он и бывает.