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 KAA26642; Tue, 12 Jun 2001 10:31:14 +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 KAA26664 for ; Tue, 12 Jun 2001 10:31:13 +0200 (MET DST) Received: from psyche.kaba.or.jp (psyche.kaba.or.jp [202.249.19.1]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f5C8V8j04713; Tue, 12 Jun 2001 10:31:09 +0200 (MET DST) Received: from vortex.kaba.or.jp (vortex.kaba.or.jp [202.249.19.21]) by psyche.kaba.or.jp (8.9.3/3.7Wpl2-psyche) with ESMTP id RAA48946; Tue, 12 Jun 2001 17:31:06 +0900 (JST) Received: from localhost (pmdhcp06.kaba.or.jp [202.249.19.118]) by vortex.kaba.or.jp (8.9.3/3.7W) with ESMTP id RAA03757; Tue, 12 Jun 2001 17:31:05 +0900 (JST) To: Pierre.Weis@inria.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] let mutable (was OCaml Speed for Block Convolutions) In-Reply-To: <200106120743.JAA25545@pauillac.inria.fr> References: <20010612122114X.garrigue@kurims.kyoto-u.ac.jp> <200106120743.JAA25545@pauillac.inria.fr> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010612173117N.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 12 Jun 2001 17:31:17 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Bonjour Pierre, > > 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. I didn't ask for one. I'm basically agreeing with you that once we have a good property, we shall stick to it. My remark was just that it was not a completely unreasonable way to explain the behaviour of assignment, and that thanks to good properties, this was kept simple. > A more interesting contribution would be to give evidences that > references and arrays and other imperative features are indeed built > with lvalues in Caml. Indeed the type checker has an individual case for each of the assignment constructs, so the parallel with lvalues is only on surface. (More precisely, only records are handled by the type checker, other ones are just syntactic sugar.) > > Also, there is one unique case currently which can only be explained > > by the distinction lvalue/rvalue: instance variables in objects. > > > 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. Indeed. > > Another answer is that people so fond of objects have already heared > > of lvalues anyway. > > So what ? I was just wondering why it is the way it is, nothing more. I suppose we're not going to change it anyway, considering the quantity of code involved. The best would be not to have it in the first place. > > 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... If we take your previous argument of evidences in the compiler, the loop variable is indeed compiled as a lvalue. There is no function involved, and the for loop goes down to the backend. But I agree that you can handle this as syntactic sugar, and provide a semantics without rvalues for it. Cheers, Jacques Garrigue ------------------- 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