[Caml-list] Lazy.Value

[Caml-list] Lazy.Value

[Daniel de Rauglaudre]

I may say nonsense, but is it possible to generalize things like:
   ref (Lazy.Value [])

It would help me to have 'a streams (for the empty one) without an
horrible hack in the present implementation which even create bugs in
some circumstances.

I am writing a library (and a syntax) for functional streams and
parsers in Camlp4. I did not put my hack in that version, but the
result is that the empty one is of type '_a Fstream.t.

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

Re: [Caml-list] Lazy.Value

[Xavier Leroy]

> I may say nonsense, but is it possible to generalize things like:
>    ref (Lazy.Value [])

No, this would be unsound -- like all polymorphic references.

                let r = ref (Lazy.Value []) in
                  r := Lazy.Value [1];
                  match !r with [f] -> f 0  (*crash*)

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Lazy.Value

[Daniel de Rauglaudre]

> > I may say nonsense, but is it possible to generalize things like:
> >    ref (Lazy.Value [])
> 
> No, this would be unsound -- like all polymorphic references.

I know, and I knew perfectly your example, but for Lazy, it is
different. The structure of this type is visible only because it is
necessary for the "lazy" statement. Users are not supposed to change
the reference value by hand.

And when the "Value" is obtained, the lazy is no more changed by Lazy.force.

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

Re: [Caml-list] Lazy.Value

[Xavier Leroy]

> > No, this would be unsound -- like all polymorphic references.
> 
> I know, and I knew perfectly your example, but for Lazy, it is
> different. The structure of this type is visible only because it is
> necessary for the "lazy" statement. Users are not supposed to change
> the reference value by hand.

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.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Lazy.Value

[Daniel de Rauglaudre]

> 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