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=2.3 required=5.0 tests=HTML_10_20,HTML_MESSAGE, SPF_NEUTRAL 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 2659DBC69 for ; Sat, 10 Mar 2007 06:08:18 +0100 (CET) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2A58GG6019157 for ; Sat, 10 Mar 2007 06:08:17 +0100 Received: by wx-out-0506.google.com with SMTP id i26so1114141wxd for ; Fri, 09 Mar 2007 21:08:16 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tq6ZCIB0T9gtOzrFn3noGt8lkKRtnzcyU6QtKkvV16cScc+Q72BmfCLR8rmqFT91FSm/1KuHcEAgUGfdMOjl/3yFiHfKHtFUNGPLHuLtcB7Xm978lUiayurBVrR6iDjYFyyLaBjmsMWyvnH0bSy/IPqDmLdNud8R/id/tFl1CAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=UNOqCSrWHWam4WFQTwxwoyw+GaBS5H70MEWWX7+XCQC1kK96YAM+sPAJS7eqKigJzaemeJx50hPFrI+lAJGaTulvQDYpxVUDXVjmB0eh4l7f5hEzA/fqO0NUnAdqBppwOiGJLrQsYLcA/6ntZTDAjcdiiD61J6jsOb5L9k4VlyE= Received: by 10.90.95.11 with SMTP id s11mr316677agb.1173503296509; Fri, 09 Mar 2007 21:08:16 -0800 (PST) Received: by 10.90.96.17 with HTTP; Fri, 9 Mar 2007 21:08:16 -0800 (PST) Message-ID: <4d5f7bec0703092108x78de8ca0s2e79451265281b61@mail.gmail.com> Date: Sat, 10 Mar 2007 00:08:16 -0500 From: "Daniel Andor" To: Andrej.Bauer@andrej.com Subject: Re: [Caml-list] Operator overloading Cc: caml-list@yquem.inria.fr In-Reply-To: <45F14E4E.6040200@fmf.uni-lj.si> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4204_2669262.1173503296438" References: <3D1E4D9CA9BCE04D8F2B55F203AE4CE30666AB74@selma.roomandboard.com> <45F14E4E.6040200@fmf.uni-lj.si> X-j-chkmail-Score: MSGID : 45F23D41.000 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 45F23D41.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; overloading:01 andrej:01 andrej:01 overloading:01 0,1:01 0,1:01 inference:01 syntax:01 computes:01 syntax:01 inference:01 computes:01 wrote:01 wrote:01 typing:01 ------=_Part_4204_2669262.1173503296438 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 3/9/07, Andrej Bauer wrote: > > To all who like overloading, I dearly suggest that they explain to > themselves the following bit of Mathematica: > > In[1]:= f[v_] = {{1,0}, {1,1}} . (v + {0,1}); > > In[2]:= f[{0,0}] > > Out[2]= {{0, 0}, {1, 1}} If you define the function f as most people would expect a function to work, and the way you would be taught in Mathematica to define a function, and the way you define 95% of your functions, you get the expected answer: In[1]:= f[v_] := {{1,0}, {1,1}} . (v + {0,1}); In[2]:= f[{0,0}] Out[2]= {0, 1} So I think you are a little disingenuous in your example... ;) Lots of interesting and sophisticated reasons have been given for the pros and cons of overloading. As someone who programs numerical code on a daily basis, I would just like to make a practical comment: A reason to appreciate strong typing (and inference that makes it brief) is that it catches a good number of bugs. When programming mathematical algorithms, not having overloading increases the complexity of the code and hence introduces bugs. Why? Most mathematicians I know syntax highlight with their eyes. Complexity thwarts this process. (Until you have a programming language that checks the algorithm as well as computes it, this human syntax highlighter is the best (well, only) thing you've got.) I do occasionally get caught by the kind of error that Andrej mentions. But nonetheless I still reach for Mathematica, because algorithmic correctness (which depends on my interaction with the computer) is at least as important to me as type safety. You know, if efficiency didn't matter, then we could all still prove our programs with pencil and paper and then program it in assembler (or punchcards). Can't there be a systematic way of doing this overloading that will not upset people while allow me (and Jon?) to `see' clearly? There's got to be a way! :) $0.0314, Daniel. ------=_Part_4204_2669262.1173503296438 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 3/9/07, Andrej Bauer <Andrej.Bauer@fmf.uni-lj.si> wrote:
To all who like overloading, I dearly suggest that they explain to
themselves the following bit of Mathematica:

In[1]:= f[v_] = {{1,0}, {1,1}} . (v + {0,1});

In[2]:= f[{0,0}]

Out[2]= {{0, 0}, {1, 1}}

If you define the function f as most people would expect a function to work, and the way you would be taught in Mathematica to define a function, and the way you define 95% of your functions, you get the expected answer:

In[1]:= f[v_] := {{1,0}, {1,1}} . (v + {0,1});

In[2]:= f[{0,0}]

Out[2]= {0, 1}

So I think you are a little disingenuous in your example... ;)

Lots of interesting and sophisticated reasons have been given for the pros and cons of overloading.  As someone who programs numerical code on a daily basis, I would just like to make a practical comment:

A reason to appreciate strong typing (and inference that makes it brief) is that it catches a good number of bugs.  When programming mathematical algorithms, not having overloading increases the complexity of the code and hence introduces bugs.  Why?  Most mathematicians I know syntax highlight with their eyes.  Complexity thwarts this process.  (Until you have a programming language that checks the algorithm as well as computes it, this human syntax highlighter is the best (well, only) thing you've got.)

I do occasionally get caught by the kind of error that Andrej mentions.  But nonetheless I still reach for Mathematica, because algorithmic correctness (which depends on my interaction with the computer) is at least as important to me as type safety. 

You know, if efficiency didn't matter, then we could all still prove our programs with pencil and paper and then program it in assembler (or punchcards).

Can't there be a systematic way of doing this overloading that will not upset people while allow me (and Jon?) to `see' clearly?  There's got to be a way!  :)

$0.0314,
Daniel.
------=_Part_4204_2669262.1173503296438--