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 KAA23415; Sat, 14 Jul 2001 10:51:50 +0200 (MET DST) 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 KAA23420 for ; Sat, 14 Jul 2001 10:51:49 +0200 (MET DST) Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f6E8pnf12124 for ; Sat, 14 Jul 2001 10:51:49 +0200 (MET DST) Received: from beertje.william.bogus (williamc.xs4all.nl [213.84.56.92]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id KAA18335; Sat, 14 Jul 2001 10:51:46 +0200 (CEST) Received: (from williamc@localhost) by beertje.william.bogus (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f6E8qmv17437; Sat, 14 Jul 2001 10:52:48 +0200 X-Authentication-Warning: beertje.william.bogus: williamc set sender to williamc@paneris.org using -f From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15184.2142.889640.404096@beertje.william.bogus> Date: Sat, 14 Jul 2001 10:52:46 +0200 (CEST) To: caml-list@inria.fr Subject: [Caml-list] RFC: get/set vs get/ref In-Reply-To: <3B4D020D.4039A62F@maxtal.com.au> References: <0107111558020P.12210@baxter> <00a701c10a15$9b1db190$6701a8c0@abeast1.com> <3B4D020D.4039A62F@maxtal.com.au> X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk John Max Skaller writes: > The difference is exemplified by the following techniques > for incrementing a character: > > s.set ((s.get(pos) + 1),pos) // get/set method > s.ref(pos).++ // ref method > > Clearly, ref methods are more powerful and more efficient, > but on the other hand they expose the underlying implementation > and prevent hooking changes to the mutable state. I was a little disappointed that while ocaml compiles the "bare" increment case right, a.(i) <- a.(i) + 1 => addl $2, -2(%eax, %ebx, 2) it doesn't do such a good job on let set s i y = s.a.(i) <- y and get s i = s.a.(i) in fun s i -> set s i ((get s i) + 1) => movl (%eax), %ecx movl -2(%ecx, %ebx, 2), %ecx addl $2, %ecx movl (%eax), %eax movl %ecx, -2(%eax, %ebx, 2) apparently because of the lack of common subexpression elimination (the CS here being `s.a'). The argument against CSE seems to be that it doesn't do anything the programmer can't do for themselves, probably with a net gain in readability, if they really care. But I have seen several examples like Max's where it would actually help in reducing the cost of crossing an abstraction barriers. (By the way, KAI's famous optimising C++ actually INTRODUCES common subexpressions and leaves them for the platform C backend to eliminate! If you define a variable using a const expression and never modify it, it goes through substituting the expression wherever the variable appears. The idea I suppose is to create opportunities for constant folding etc. But it is extremely frustrating with gcc, which doesn't always do the expected CSE completely---there is absolutely no way to work around it short of introducing a spurious global reference to the variable. This is an example of over-complex and unpredictable optimisation making trouble for the programmer. Nevertheless I do think a little more support in ocaml for cost-free abstractions would be a win.) ------------------- 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