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 LAA21140; Fri, 7 Jun 2002 11:09:10 +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 LAA21138 for ; Fri, 7 Jun 2002 11:09:09 +0200 (MET DST) Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g57998H07087 for ; Fri, 7 Jun 2002 11:09:08 +0200 (MET DST) Received: from d1o960.telia.com (d1o960.telia.com [195.252.60.241]) by maild.telia.com (8.11.6/8.11.6) with ESMTP id g57998s25119; Fri, 7 Jun 2002 11:09:08 +0200 (CEST) Received: from [195.252.60.182] (t2o960p62.telia.com [195.252.60.182]) by d1o960.telia.com (8.8.8/8.8.8) with ESMTP id LAA08944; Fri, 7 Jun 2002 11:09:06 +0200 (CEST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 07 Jun 2002 11:13:24 +0200 Subject: Re: [Caml-list] look operator From: Winfried Dreckmann To: Michel Quercia CC: Message-ID: In-Reply-To: <20020606170842.7ac394b7.michel.quercia@prepas.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk on 06.06.2002 17:08 Uhr, Michel Quercia at michel.quercia@prepas.org wrote: > The "look" operation should be restricted to local use only, and the > "copy_out" operation should be used whenever > it can not be proved that r will never be modified again." Thanks for your long explanations. I understand that you are concerned with the safety problem. > Right, and should such an operation become standard, then the compiler should > check that the tref "r" becomes unreachable after the last "look" (this may be > easier to say than to implement). I think it's an interesting idea which one should keep in mind. > I think overloading is absolutely necessary when dealing with numerical data. > ... > When such an overloading mechanism will be available, the "look" operation > will disappear at the next Numerix release (but not the "trefs"). That would be the best solution. Not the "trefs" of course. Having t's and tref's together is the best part. >> I could, for instance, also imagine an abstract assign operator >> >> val set : tref -> t -> unit >> >> where the contents of t is not copied but assigned to tref, and thus made >> mutable, which could be useful in certain restricted ways. > > This is too dangerous : > > let e1 = ... and e2 = ... in > set r (if ... then e1 else e2); > xxx_in r ...; > > (* try and guess what will be e1 and e2 now *) Definitely. Actually I was thinking about implementing matrices with mutable entries where for efficiency reasons the implementation type of entries would be t, and of course implementation details would be hidden by the interface. To do this with Numerix one would at least need a function val set : tref -> t matrix -> int -> int -> unit to make matrix entries accessible to in-place operations (with an subsequent update to make sure the entries get really changed). So I thought there is more to "look" than "look", and that assignment operators are also worth considering. But this is stretching it very far. In fact, the above way of implementing matrices with mutable entries looks like a kind of unboxing, and this may be best seen, according to Xavier Leroy, as an optimization. Regards, Winfried Dreckmann ------------------- 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/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners