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=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id A48D5BC69 for ; Thu, 8 Mar 2007 18:54:26 +0100 (CET) Received: from smtp.janestcapital.com (www.janestcapital.com [66.155.124.107]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l28HsPPs008376 for ; Thu, 8 Mar 2007 18:54:26 +0100 Received: from [192.168.250.117] [209.213.205.130] by janestcapital.com with ESMTP (SMTPD-9.10) id ADD00778; Thu, 08 Mar 2007 12:54:24 -0500 Message-ID: <45F04DD0.5010505@janestcapital.com> Date: Thu, 08 Mar 2007 12:54:24 -0500 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Zumkeller Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] F# References: <3D1E4D9CA9BCE04D8F2B55F203AE4CE30666AB5E@selma.roomandboard.com> <200703081510.56667.jon@ffconsultancy.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45F04DD1.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 overloading:01 ocaml:01 functors:01 overloading:01 functor:01 comming:01 functors:01 mli:01 semantics:01 vectors:01 vectors:01 solver:01 wrote:01 imho:01 Roland Zumkeller wrote: > Wasn't there a more or less good reason for OCaml *not* to support > operator overloading? > Yes. Ocaml has modules and functors. IMHO, any time you thing "boy, it'd be really nice to use operator overloading here", you should use a module and a functor instead. I have a long post on this topic comming soon, but for now: 1) Functors state up front what operators need to be provided to the code. This is less of a problem with purely numeric code, but I've yet to see a language that allowed operator overloading and then exercised the restraint and kept them only on numeric types. At which point, having it stated in the .mli file what operators are needed, and having it checked that you're actually providing them, is nice. 2) Functors allow for more flexible semantics as to what operations need to be provided, so operations that aren't obviously operators can be required as well- for example, Newton's method likes having an "equals within epsilon" function, or norm operation, neither of which are really operators. 3) Functors allow for more types- for example, if you're doing Newton's method on complex numbers, the type of an epsilon, or the type of a norm, is not a complex number, but instead just a real. Or if you're doing Newton's method on vectors, the type of the derivitive is a matrix. These are easy to express this with functors, hard to do with operator overloading. 4) Functors make it easier to swap in alternate implementations of various operations. For example, doing Newton's method on vectors, you end up needing to calculate b/A, where A is a matrix and b a vector. This is easy enough to translate as solving Ax=b, you standard linear system. It's nice to be able to switch out which linear system solver you want to use with functors, rather harder with operator overloading. Brian