From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA25860; Tue, 12 Jun 2001 09:43:13 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA25708 for ; Tue, 12 Jun 2001 09:43:12 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f5C7h8j02645; Tue, 12 Jun 2001 09:43:08 +0200 (MET DST) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA25545; Tue, 12 Jun 2001 09:43:07 +0200 (MET DST) From: Pierre Weis Message-Id: <200106120743.JAA25545@pauillac.inria.fr> Subject: Re: [Caml-list] let mutable (was OCaml Speed for Block Convolutions) In-Reply-To: <20010612122114X.garrigue@kurims.kyoto-u.ac.jp> from Jacques Garrigue at "Jun 12, 101 12:21:14 pm" To: garrigue@kurims.kyoto-u.ac.jp (Jacques Garrigue) Date: Tue, 12 Jun 2001 09:43:07 +0200 (MET DST) Cc: Pierre.Weis@inria.fr, caml-list@inria.fr X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > From: Pierre Weis > > > > > 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