Hi Pierre,

> On the language design side, we worked hard to bypass the limitations
> of letrefs in order to design first class citizens references, and to
> get rid of left values in the language. On the compiler construction
> side, Xavier worked hard to optimise spurious allocations of
> references that can be treated as vars. I think we now have the power
> and conceptual simplicity of references along with the runtime
> efficiency of letrefs, I don't see the point to introduce a new
> arguably useless construct.

I agree with most of what you say, but only in the sense that I would
agree that "mutable" is not really needed for record fields either, and
that programmers could be forced to live with Standard ML's "ref" just
to keep the language slightly simpler.  

But then why is "mutable" on record fields better for the working
imperative programmer?  Firstly because it's just closer to C.  But I
think it might also be the case that using "mutable" is just lighter on
the programmer's mind than using "ref".  My feeling is that the same
holds true for let-bound variables.  

[ To expand on why "mutable" fields are, IMHO, so much better...  In
Standard ML "refs" get used in data structures for four main purposes: 
  - to get values that can be compared by pointer equality; 
  - to ensure sharing of an allocation cell; 
  - to allow "regular" mutation; 
  - to cope with initializing recursive data structures using "ref
option".  

Because of these multiple uses I honestly used to get "ref" type
constructors nested two or three deep (when designing some
pointer-chasing graph structures)!!  

I was never able to get this code right until I switched to Caml,
precisely because my structures became simpler.  In Caml the combination
of inbuilt pointer equality and "mutable" made things sufficiently
simple, and the ability to allocate at least some recursively linked
objects without using "ref option" also helped.  
]

Mutable let-bound variables aren't as important as mutable fields, but I
don't see any great harm in having them.  OCaml is almost a truly great
imperative programming language, and I reckon if you added these then
you'd be a bit closer to this goal.  But at the moment C programs still
look like a bit of a mess when translated over to OCaml: too many "refs"
and "!"s...  These are fine if you're writing the stuff, but look pretty
crazy when you show the code to a C programmer (for starters ! gets
confused with C's "not"...)

(As an aside I will mention that I would like to see some remaining
problems solved: specifying enforced sharing by some other means than
using refs; and being able to "tie the knot" on recursive structures
that extend beyond a finite number of simultaneously allocated
cons-cells, without using "ref option". I guess both of these are pretty
hard to solve.  More realistically, I also don't see any harm at all in
having an extended "for" loop construct much as I proposed a year or so
ago.)

Don

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr