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 FAA32188; Fri, 15 Jun 2001 05:22:06 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA32446 for ; Fri, 15 Jun 2001 05:22:01 +0200 (MET DST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id f5F3M0j19850 for ; Fri, 15 Jun 2001 05:22:00 +0200 (MET DST) Received: from 157.54.1.52 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Jun 2001 20:21:55 -0700 (Pacific Daylight Time) Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 14 Jun 2001 20:20:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Caml-list] let mutable (was OCaml Speed for Block Convolutions) Date: Thu, 14 Jun 2001 20:20:22 -0700 Message-ID: <0C682B70CE37BC4EADED9D375809768A05BF6029@red-msg-04.redmond.corp.microsoft.com> Thread-Topic: [Caml-list] let mutable (was OCaml Speed for Block Convolutions) Thread-Index: AcDwQPQ3F5UO76IfTTKOAZ8Yx4xcSQFAikMg From: "Don Syme" To: "Pierre Weis" , "Jacques Garrigue" Cc: X-OriginalArrivalTime: 15 Jun 2001 03:20:25.0117 (UTC) FILETIME=[1E4DBCD0:01C0F54A] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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. =20 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. =20 [ To expand on why "mutable" fields are, IMHO, so much better... In Standard ML "refs" get used in data structures for four main purposes:=20 - to get values that can be compared by pointer equality;=20 - to ensure sharing of an allocation cell;=20 - to allow "regular" mutation;=20 - to cope with initializing recursive data structures using "ref option". =20 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)!! =20 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. =20 ] 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