> 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.

Right.

In the present implementation of stream.ml, 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
general.

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.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr