Browse thread
Help me find this pdf
[
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: | skaller <skaller@u...> |
| Subject: | Re: [Caml-list] Help me find this pdf |
On Thu, 2007-10-18 at 18:18 +0100, Jon Harrop wrote: > Because you can't pattern match over lazy values, this solution is about as > beautiful as my first girlfriend. Hopefully both GF and wife class as 'eager' not 'lazy' .. :) > This is no freakishly theoretical problem either, it crops up whenever I want > to destructure a collection as a sequence. You can use an unfold but that > only buys you 1 element look ahead whereas the power of pattern matching > stems from its ability to dispatch based upon destructuring to arbitrary > depths. That's not quite right. Pattern matching in Ocaml has bound look ahead. Although the bound depends on the actual patterns, there is always a bound on the depth for any given match. The branch expression is evaluated lazily, so you can use recursion to unfold with bound lookahead. Actually it isn't necessary to cache the lookahead values, and indeed Felix does not: any bindings in the branch expression are actually re-evaluated, independently of the matching. Caching forced values isn't mandatory, and not necessarily efficient. > If it were possible to pattern match over lazy values, you would simply write > a to_lazylist function in the module of each container and pattern match over > its result to dissect any container with minimal copying. What it seems to come down to is the same as in Felix: it isn't enough to have lazy application: the alternation and product combinators have to be lazy too, in both their introduction and elimination parts. Hmm .. is this right? -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net