e = f . g

sincos = sin . cos

fact n = product [1..n]

• http://www.haskell.org/haskellwiki/DDC -- Disciple is an explicitly lazy dialect of Haskell which supports destructive update, computational effects, type directed field projections and allied functional goodness.
  
  Было бы замечательно посмотреть на сравнение производительности и на реализацию уже существующих ленивых структур на этом чудном диалекте. Вряд-ли будет разница в разы.
  
  
• Неужели тут никто не может пользоваться поисковиками, либо на худой конец почитать википедию и найти там описание хаскеля и ленивых вычислений? Люди уже привели pros and cons, почему бы не посмотреть? Да, всё в итоге можно свести к программе для тьюринг машины, но вопрос стоит в удобстве написания! Да, ленивые вычисления помогают строить и оперировать с бесконечными структурами данных. Да, то же самое можно сделать с помощью итераторов, ну и что? Только ленивость по умолчанию позволяет избежать оперирования ненужными сущностями и избежать обдумывания деталей реализации. Разве плохо?
  
  
• Сделать быструю реализацию какого-нибудь факториала/умножения матриц на Си элементарно. Хаскель на этой задаче будет медленным (опять же, если не использовать специально предназначенные для этого библиотеки с ручной оптимизацией кода). Да, при сравнении хаскелла и других языков первый часто "выезжает" только за счёт использования более "продвинутых" алгоритмов. А при одном и том же алгоритме работает медленее. Но почему никто не думает о том, что реализации более сложного алгоритма на хаскелле может оказаться быстрее кодирования простого алгоритма на Си? Разве скорость написания и прототипирования ничего не значит?

-- | переключалка между несколькими сценами
scene = state1
    where state1 = switch scene1 [event1 --> state2,
                                  event2 --> state3]
          state2 = switch scene2 [event3 --> ...]
          ...
          stateN = ...

-- | тупой счетчик
counter n = switch (pure n) [tick --> counter (n+1)]

(** переключалка между несколькими сценами *)
let scene = 
  let rec state1 _ = switch scene1 [event1 -=> state2,
                                    event2 -=> state3]
  and     state2 _ = switch scene2 [event3 -=> ...]
  ...
  and     stateN _ = ...
  in
    state1 ()

(** тупой счетчик *)
let rec counter n = switch (pure n) [tick -=> fun _ -> counter (n+1)]

Prelude> [1,2] >>= (\x -> [10+x,20+x])
[11,21,12,22]

I did extensive research on all of the most popular functional languages last
year, including Haskell. In case you are trying to do something similar, I'll
warn you that almost all of the examples of Haskell's use in industry are
fakes, e.g. companies that have no products, companies that have one product
that never used Haskell, companies that happen to have two Haskell advocates
working for them out of 150 developers, companies where one employee once did
a preliminary Haskell program but nothing since and, finally, plain old spam
where companies that have never had anything to do with Haskell have hijacked
the Haskell site to advertise on-line only to be hailed as a "real world"
example of Haskell in industry by its proponents. I was rather baffled when I
discovered this and have never seen behaviour like it.

//Caml-list Digest, Vol 38, Issue 20

Debian and Ubuntu registered installs
-------------------------------------
184,574: FFTW (14,298 lines of OCaml)
 12,866: Unison (23,993 lines of OCaml)
  7,286: MLDonkey (171,332 lines of OCaml)
  4,365: Darcs (3,939 lines of Haskell)
  4,066: FreeTennis (7,419 lines of OCaml)
  4,057: Planets (3,296 lines of OCaml)
  3,465: HPodder (2,225 lines of Haskell)
  2,965: LEdit (2,048 lines of OCaml)
  2,822: Hevea (11,596 lines of OCaml)
  2,657: Polygen (1,331 lines of OCaml)

open ExtString;;
open ExtList;;

let (>>) f g = g f;;
let flip f x y = f y x;;
let wordvalue s = String.enum s >> Enum.map (fun c->int_of_char c - 64) >> Enum.fold (+) 0;;
let triangs = Enum.init 20 (fun n-> (n+1)*(n+2)/2) >> List.of_enum;;
let istriang s = if List.mem (wordvalue s) triangs then 1 else 0;;

"words.txt" >> Std.input_file >> flip String.nsplit "," >> List.enum >>
Enum.map (fun s->String.sub s 1 (String.length s - 2)) >> Enum.map istriang >> Enum.fold (+) 0 >> print_int;;

Это не засчитывается за значимый опыт разработки. Это так называемое "экспериментальное программирование".

G>>Удивительно, как же у тебя тогда-то получилось мне все объяснить, буквально год назад, а сейчас ты почему-то даже не пытаешься, все больше взываешь у духу святого Вадлера и грозишь гневом монад.

Короче, ты сторонник преждевременной оптимизации.

L>Ты хочешь, чтобы я показал, что ленивый код лаконичен? Или что лаконичность — это преимущество, я не очень понимаю, что от меня требуется.

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

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

Опровергать тезис по существу будешь? Я бы хотел наглядный и убедительный контрпример, лишенный эмоций и шелухи.

Since the Newton-Raphson algorithm computes a sequence of approximations it is natural to represent this explicitly in the program by a list of approximations.
Each approximation is derived from the previous one by the function

next N x = (x + N/x) / 2

so (next N) is the function mapping one approximation onto the next. Calling this function f, the sequence of approximations is

[a0, f a0, f(f a0), f(f(f a0)), ..]

We can define a function to compute this:

repeat f a = cons a (repeat f (f a))

so that the list of approximations can be computed by

repeat (next N) a0

using System.Console;
using System.Collections.Generic;

module Program
{
  Repeat[T](n : T, f : T -> T) : IEnumerable[T]
  {
    def loop(n)
    {
      yield n;
      loop(f(n))      
    }
    
    loop(n)
  }
  
  Main() : void
  {
    def res = Repeat(1, x => x + 1); // Для наглядности применяем простой инкремент 
    WriteLine("Мы получили бесконечный список :)");
    foreach (x in res)
      WriteLine(x);
  }

L>б) А что на Камлах и Немерлях пишут — map f . map g . map h? Или всё таки map (f . g . h)?

VD>>Не видел подобных проблем в не ленивых языках.

VD>>Вообще, надо бы стравить Лиспаря и Хаскелиста... и поглядеть на получившийся флэйм.

lazy
{
  блок с ленивыми по умолчанию вычислениями.
}

L>А что в С# код прямо так превращается в машинные команды, безо всяких разных преобразований?

В теории практика и теория аналогичны.
На практике же — нет.

f x y = z
  where
     z = g w
     w = m x y

VD>Ну, я же не говорил, что Гапертон гений, а ты нет?

f :: Int -> Int -> Int
f a b = a + b

f :: Int -> Int -> Int
f 0 b = b
f a b = a+b

f :: Int -> Int -> Int
f !a !b = let s = a + b in s `seq` s

G>Удивительно, как же у тебя тогда-то получилось мне все объяснить, буквально год назад, а сейчас ты почему-то даже не пытаешься, все больше взываешь у духу святого Вадлера и грозишь гневом монад.

Видишь ли, я для себя всегда сам решаю, что для меня перевешивает.
http://rsdn.ru/forum/message/3218948.1.aspx

Автор: Gaperton
Дата: 18.12.08

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

G>Примерно такая хронология событий. А-аставайтесь с нами.

*Main> foldr (\x list -> x+1:1:list) [] [1,error "aaa!!!",2]
[2,1,*** Exception: aaa!!!
*Main> take 2 $ foldr (\x list -> x+1:1:list) [] [1,error "aaa!!!",2]
[2,1]

T>f :: Int -> Int -> Int
T>f !a !b = let s = a + b in s `seq` s
T>

f :: Int -> Int -> Int
f a b = id $! a + b

{-# LANGUAGE BangPatterns #-}
main = print ((\ !x !y -> x+y) (2+2) (4-1))

VD>Так что для реальной жизни важно чтобы map, fold, filter, forall и т.п. не проигрывали по скорости аналогичным циклам в компилируемых языках. А ленивы он или нет дело десятое.

В цепочке map/filter/fold важно ленивы они или нет. Неленивые — неэффективны (или вообще невозможны для бесконечных списков). Поэтому так популярны итераторы.