Re: [Caml-list] let mutable (was OCaml Speed for Block Convolutions)

[Pierre Weis <Pierre.Weis@inria.fr>]

> From: Pierre Weis <Pierre.Weis@inria.fr>
> 
> > > > This construction would have introduced the notion of
> > > > Lvalue in Caml, thus introducing some additional semantics complexity,
> > > > and a new notion to explain to beginners.
> > > 
> > > Lvalues already exist in Ocaml (and have to be explained to
> > > beginners), for example : "a.(i) <- a.(i)+1".
> > 
> > I'm afraid this is wrong.
> > 
> > The syntactic construction e1.(e2) <- e3 is a short hand for a
> > function call: Array.set e1 e2 e3. Once more there is no Lvalue here,
> > just a regular function call (hence you can write arbitrary complex
> > expressions in place of e1, provided it returns an array value).
> > 
> > I'm a bit surprised that you feel it necessary to explain the notion
> > of Lvalue to beginners when there is no such notion in the language !
> 
> You can of course explain the semantics this way, but most people
> apparently consider that there are lvalues in ocaml, just that they
> are very restricted. It is certainly much simpler to explain than
> lvalues in C!

Most people consider Caml as a toy language, since it is not a
mainstream language. As a computer science researcher fond of riguour,
I certainly will not organize a vote to find out if ``most people
apparently consider'' something, to decide that this something is
true.

A more interesting contribution would be to give evidences that
references and arrays and other imperative features are indeed built
with lvalues in Caml.

> Also, there is one unique case currently which can only be explained
> by the distinction lvalue/rvalue: instance variables in objects.
> 
>   class counter = object
>     val mutable x = 0
>     method get = x
>     method bump = x <- x + 1
>   end
> 
> How can you explain the method bump without the notion of lvalue?

I can't and I just consider the introduction of lvalues to model
states in objects as a flaw in the design of this feature (and I
certainly never have promoted it). Reintroduction of lvalues just for
this questionable facility is an error.

> Perfectly coherent answers would be, let's remove mutable instance
> variables, or force the notation self.x to access variables.

Yes. That's what we should have done, since we love perfectly coherent
answers for Caml.

> Another answer is that people so fond of objects have already heared
> of lvalues anyway.

So what ?

I cannot consider such a vague argument as a satisfactory answer to an
important language design decision, since this ``answer'' is not a
language design consideration. If we were using this kind of general
public oriented reasons as guidelines to develop the semantics of the
language, you could imagine I could state that ``people so fond of
objects have already heared of bus error anyway'', which is also true
I'm afraid, to justify the introduction of a feature that would cause
some bus errors from time to time!

> the problem is not only with lvalues either. With for loops, you have
> a case of rvalue, where something which is not syntactically a
> function have a changing variable, which is accessed directly. The
> fact you cannot change it yourself is not relevant.

What do you mean here ? A for loop being just a shorthand for the
definition of a function, I don't see the problem...

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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