From: Pierre Weis <Pierre.Weis@inria.fr>

> I consider the ``| simple_expr0 LESSMINUS expr'' rule as perfectly
> acceptable, but I decided to keep this syntactic construct ident <-
> expr for ``variables'' assignment, i.e. for a future reintroduction of
> good old letref lvalues of the original ML (alias your ``references
> certified not to be returned or passed to functions. Easy.'', wish No
> 1 of your presonal wish list).

In fact they are already here, with fields in objects.
Just that you can only use them inside objects.
So you were clever to keep it :-)

> > So here is also my wishlist for Santa Xavier.
> > 
> > * addition of let mutable ... in
> >        let mutable x = 0 in
> >        for i = 1 to do x <- x + i done;
> >        x
> >   The idea is to have references which are certified not to be
> >   returned or passed to functions. Easy.
> >   Makes lots of thing clearer, but it might be a good idea to allow
> >   only the let ... in form, since toplevel let mutable is rather
> >   opposed to functional programming.
> 
> You forgot to mentioned that this feature also adds a lot of
> complexity: as a kind of witness of this extra difficulty, we can
> observe that you immediately suggest to restrict the construct to
> local forms. I suppose that this is not for the vague philosophical
> reason you mentioned (``let mutable is rather opposed to functional
> programming''), but more seriously to avoid real difficulties, such as
> complex typechecking problems (with value polymorphism restriction ?),
> or even compilation and semantics problems.

Really, I don't think it would be useful at toplevel.
I view let mutable .. in as a way to provide some state, but
immediately cleanly wrapped, either by only being used locally, or
in exported functions.
This is completely similar to mutable object fields; both the goal and
the method.

> For instance, what do we
> do if such a letref variable is assigned to, from within the body of a
> function (that could be exported) ?

This is just syntactic sugar for references, which is why I said it
was easy. Similarly typing is just the typing of references.

> Furthermore, this construct would add an entirely
> new notion to Caml: lvalues.

As stated above: they are already here, object fields.
You may think of it as a good or bad idea, but the distinction
between it and the fact a.x behaves differently when there is a <- and
when there is none is subtle.

But well, this was only first in my wish list because I was answering
to a message related to that. My personal priority is much lower.

> > * addition of let open ... in
> >        module P2d = struct type t = {x:int;y:int} end
> >        module P3d = struct type t = {x:int;y:int;z:int} end
> >        let f2d p1 p2 =
> >          let open P2d in
> >          {x = p1.x + p2.x; y = p1.y + p2.y}
> >   Extremely easy.
> 
> I hope it is ``Extremely easy''. Remember that Pascal has been
> criticised for its ``with'' construct that locally introduces new
> names in programs in a completely silent way. Are you sure this is a
> desirable feature ?

I think this is different: modules are already a way to organize the
namespace, and this allows you to do it more locally. You can already do
it with camlp4, so what?

> > * have a notation to abbreviate the OCAMLLIB directory in include
> >   paths. One could write
> >        ocamlc -c -I +labltk -I +lablGL gears.ml
> >   rather than
> >        ocamlc -c -I `ocamlc -where`/labltk -I `ocamlc -where`/lablgGL gears.ml
> > 
> > I would be already satisfied with only one of these...
> 
> So you are already satisfied, since you can write
> 
>   ocamlc -c -I +camltk -I +camlimages ocaml_unreal_t.ml
> 
> in the current development version!

Great! I had seen the introduction of -where, but didn't catch this
one.
Thanks, Papa Weis !

Jacques