English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2001-05-28 (13:43)
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 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

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 caml-list-request@inria.fr.  Archives: http://caml.inria.fr