Browse thread
Unexpected restriction in "let rec" expressions
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Loup Vaillant <loup.vaillant@g...> |
| Subject: | Re: [Caml-list] Unexpected restriction in "let rec" expressions |
Yahoo! I got it, many thanks! 2008/2/27, Pal-Kristian Engstad <pal_engstad@naughtydog.com>: > Loup Vaillant wrote: > > loop :: ((a,c) -> (b,c)) -> a -> b > > loop f a = b > > where (b,c) = f (a,c) > > Remember that values in Haskell are lazy, which simply means that they > are pointers to things that is either a pointer to a function to > evaluate it, or the cached value. (This works, since all Haskell values > are immutable.) No problem with that. I just have some subtleties to learn about lazy graph reduction yet. What is a bit harder is to turn myself in a strictness analyzer when writing lazy code in my favorite strict language :-). > [...] > > In other words, we're telling the compiler: Given a function f :: (a, c) > -> (b, c) and a value of type a, loop f a will give the result b by > evaluating (b, c') = f (a, c) where c' == c always. That is the explanation I have waited for. I didn't have the idea to push mathematical reasoning to the end, so I continued to bother myself with an order of evaluation (even lazy), forgetting what a non strict semantic really means. Thank you. Loup PS: do you use Ocaml (or whatever FP language or technique) at naughtydog? What for, then (provided you can tell me, of course)?