Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Lazy.Value
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Daniel de Rauglaudre <daniel.de_rauglaudre@i...>
Subject: Re: [Caml-list] Lazy.Value
> OK, I see what you mean.  If "lazy e" had a special typing rule and a
> special compilation rule -- instead of being expanded into
> "ref (Lazy.Delayed (fun () -> e))" during parsing -- then it would be
> safe to treat it as generalizable, indeed.


In the present implementation of, streams are not mutable
and are "muted" by Obj.set_field. It is hack to allow the empty stream
to be an 'a stream. I thought that it could not create problems, since
it is hidden in the implementation.

But it created a problem (somebody sent me a bug report a long time
ago), due to an optimization in the compiler. I would like to remove
my hack but the consequence is that the empty stream would not be

This is for the moment accepted:
   let s = [< >] in [< '1; s >], [< 'true; s >];;

If I program "clean" streams, this would be rejected, except if lazies
can be typed like you say.

- I don't know if this lazy would be useful in other circumstances. It
  is the only case I know.

- Or we could accept a new version of not-generalized clean streams, but I
  don't know if it would be a problem for people using streams.

It is a problem to restrict things from a version to another, since
according to Murphy's law, there are always people for whom the old
version was absolutely essential. But perhaps not.

To unsubscribe, mail  Archives: