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 MAA15754; Fri, 8 Jun 2001 12:25:23 +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 MAA15636 for ; Fri, 8 Jun 2001 12:25:22 +0200 (MET DST) Received: from mrwall.kal.com (mrwall.kal.com [194.193.14.236]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id f58APLn29077 for ; Fri, 8 Jun 2001 12:25:21 +0200 (MET DST) Received: from mrwall.kal.com [194.193.14.236] (HELO localhost) by mrwall.kal.com (AltaVista Mail V2.0J/2.0J BL25J listener) id 0000_0045_3b20_a89b_35ec; Fri, 08 Jun 2001 11:27:39 +0100 Subject: RE: [Caml-list] let mutable (was OCaml Speed for Block Convolutions) Date: Fri, 8 Jun 2001 11:23:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <8E31D6933A2FE64F8AE3CC1381EEDCE704C3D4@NT.kal.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: [Caml-list] let mutable (was OCaml Speed for Block Convolutions) Thread-Index: AcDvrLDOdsQATmLRTB+5jz876Vm5VwAS/m+wAAMpX1A= From: "Dave Berry" To: "Dave Berry" , "Jacques Garrigue" , Cc: , Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Let me refute my own suggestion. If people do want the ability to specify stack allocation, they will want it for immutable values as well as mutable values. So it should be a separate, orthogonal construct. -----Original Message----- From: Dave Berry=20 Sent: 08 June 2001 10:00 To: Jacques Garrigue; tom7ca@yahoo.com Cc: williamc@paneris.org; caml-list@inria.fr Subject: RE: [Caml-list] let mutable (was OCaml Speed for Block Convolutions) One possible reason for adding "let mutable" would be to specify that escapes (such as the one Jacques gave) are explicitly disallowed. In other words, programmers could use "let mutable" to enforce the requirement that the data is stack-allocated. The compiler would report an error if it is not possible to stack-allocate, instead of silently defaulting to heap allocation. Programmers might want to do this to guarantee efficiency, or to guarantee that the memory is deallocated and does not become a potential memory leak. It might even be possible to attach finalisers to the data, which would be guaranteed to be called when the function exits, analogous to C++ destructors. However, this would complicate exception handling and possibly tail-recursion optimisations. -----Original Message----- From: Jacques Garrigue [mailto:garrigue@kurims.kyoto-u.ac.jp] Sent: 08 June 2001 00:50 To: tom7ca@yahoo.com Cc: williamc@paneris.org; caml-list@inria.fr Subject: [Caml-list] let mutable (was OCaml Speed for Block Convolutions) About the introduction of a let mutable construct, Tom _ wrote > In any case, whether or not the compiler in the > current implementation can or cannot do good type > inference and may or may not be forced to box > a floating point number, the two constructs mean > something different to the programmer, and they > behave differently. In particular "mutable x" > can never be passed around as a reference, while > "x =3D ref ..." can. If not anything else, that > prevents the programmer from inadvertently inhibiting > a compiler optimization by passing around a reference. Not exactly, the compiler may still need to build a reference. let mutable x =3D 0 in List.iter (fun y -> x <- x+y) l; x Since x has to be modified in a function called by iter, it must be wrapped into an actual reference cell. As the compiler already does a good job at unboxing only locally used references, let mutable would only be some syntactic sugar (with exactly the same typing as a reference). > Besides, the syntax is probably quite a bit more=20 > natural to imperative programmers anyway. This is actually the only argument for let mutable. I would also like such a construct, but I don't know whether its worth it. The real question is whether let mutable should be allowed at toplevel, with problems for both answers. 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 ------------------- 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 ------------------- 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