From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 4331DBC69 for ; Sat, 10 Mar 2007 04:23:33 +0100 (CET) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2A3NUHo016715 for ; Sat, 10 Mar 2007 04:23:32 +0100 Received: from ppp19-103.lns2.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.19.103]) by ipmail03.adl2.internode.on.net with ESMTP; 10 Mar 2007 13:53:29 +1030 X-IronPort-AV: i="4.14,269,1170595800"; d="scan'208"; a="60573775:sNHT21645267" Subject: Re: [Caml-list] Operator overloading From: skaller To: Brian Hurt Cc: Till Varoquaux , caml-list@yquem.inria.fr In-Reply-To: <45F18511.9060904@janestcapital.com> References: <3D1E4D9CA9BCE04D8F2B55F203AE4CE30666AB74@selma.roomandboard.com> <45F080C8.3070307@janestcapital.com> <9d3ec8300703081434r6e4987d0l5f737d873f65d9ee@mail.gmail.com> <45F18511.9060904@janestcapital.com> Content-Type: text/plain Date: Sat, 10 Mar 2007 14:23:24 +1100 Message-Id: <1173497004.14315.65.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45F224B2.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; overloading:01 pointer:01 ocaml:01 ocaml:01 pointers:01 pointers:01 statically:01 pointer:01 misused:98 sourceforge:01 closures:01 wrote:01 exception:01 caml-list:01 arithmetic:01 On Fri, 2007-03-09 at 11:02 -0500, Brian Hurt wrote: > considering wether to add a feature to a language, you have to consider > *BOTH* the valid uses of that feature *AND* the probable ways the > feature will be misused and the problems it will cause. You don't get > to ignore the downsides. Because, if you do, then there's no real > reason why introducing pointer arithmetic into Ocaml is not a good idea. Actually, using your criteria, it might a good idea IF it is possible to limit abuse in a way compatible with Ocaml philosophy. For example if you could ensure pointers always remained in bounds, or at least threw an exception when an out of bound dereference occurred. The latter seems acceptable because it is already what happens with an out of bounds access to an array. Array pointers seem easy to represent .. it's just a pair 'a Array.t * int Offset addition is statically safe, so you can throw that in too. That can be implemented with composition of closures which access record fields. However it isn't clear any of this is worth it: pointer arithmetic is used in C because it is fast, in Ocaml it probably wouldn't be, an other techniques would provide the same functionality. -- John Skaller Felix, successor to C++: http://felix.sf.net