From mboxrd@z Thu Jan  1 00:00:00 1970
Received: by margaux.inria.fr, Wed, 28 Oct 92 10:26:10 +0100
Received: by margaux.inria.fr, Wed, 28 Oct 92 10:23:44 +0100
Subject: Re: Infinite Streams in Caml Light 0.5
To: hedden@eniac.seas.upenn.edu (Jerry Hedden)
Date: Wed, 28 Oct 92 10:23:43 MET
Cc: caml-list@margaux
In-Reply-To: <9210271942.AA00591@eniac.seas.upenn.edu>; from "Jerry Hedden" at Oct 27, 92 2:42 pm
Message-Id: <9209300722.AA26987@concorde.inria.fr>
From: Michel.Mauny@inria.fr (Michel Mauny)
Reply-To: Michel.Mauny@inria.fr
Organization: INRIA, BP 105, F-78153 Le Chesnay Cedex, France
Phone: (+33) 1 39 63 57 96 -- Fax: (+33) 1 39 63 53 30
Sender: weis@margaux

> There is a point concerning streams in Caml Light that is not
> dealt with in the manual.  This involves the use of function
> calls in stream patterns.  Such calls are not evaluated in a lazy
> manner, and can cause the system to crash when a recursive
> function is used on infinite streams.  For example, the following
> function is intended to map a function over all the elements of a
> stream: 
> 
>     let rec map_stream func = function
>         [< 'x; (map_stream func) strm >] -> [< '(func x); strm >]
>       | [< >] -> [< >]
>     ;;
> 
> However, as indicated above, if `strm' is infinite, evaluation of 
> the recursive call progresses ad infinitum until "out of memory"
> occurs.

Yes, you're right: this fact should be clearly noticed in the manual.
However, this behavior of stream matching is not surprising: as
pattern-matching has a strict behavior in lazy languages,
stream-matching is also strict. One has to check completely the
left-hand part before giving control to the right-hand part of
matching rules. But I admit that it is easy to make such a mistake (I
do it quite often).

Michel Mauny