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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 5D8ABBC0B for ; Wed, 31 Jan 2007 13:54:53 +0100 (CET) Received: from sigma957.cis.mcmaster.ca (sigma957.CIS.McMaster.CA [130.113.64.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0VCsq5V020788 for ; Wed, 31 Jan 2007 13:54:53 +0100 Received: from Gorash7.UTS.McMaster.CA (Gorash7.UTS.mcmaster.ca [130.113.196.61]) by sigma957.cis.mcmaster.ca (8.13.7/8.13.7) with ESMTP id l0VCsiTZ020362; Wed, 31 Jan 2007 07:54:51 -0500 (EST) Received: from cgpsrv2.cis.mcmaster.ca (univmail.CIS.McMaster.CA [130.113.64.46]) by Gorash7.UTS.McMaster.CA (8.13.7/8.13.7) with ESMTP id l0VCsAwR014022; Wed, 31 Jan 2007 07:54:10 -0500 Received: from [74.109.166.109] (account carette@univmail.cis.mcmaster.ca HELO [192.168.1.101]) by cgpsrv2.cis.mcmaster.ca (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 160073039; Wed, 31 Jan 2007 07:54:11 -0500 Message-ID: <45C09178.8010204@mcmaster.ca> Date: Wed, 31 Jan 2007 07:54:16 -0500 From: Jacques Carette Organization: McMaster University User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stefan Monnier Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Equality of functional values References: <1170104645.4564.304.camel@penguin.local> <45BF471A.6060603@fmf.uni-lj.si> <1170165303.6391.20.camel@rosella.wigram> <45BFCF7D.5010302@fmf.uni-lj.si> <45BFDF8C.20609@mcmaster.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version-Mac: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2007.1.31.43933 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Miltered: at discorde with ID 45C0919C.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; sml:01 overloading:01 constructors:01 ocaml:01 sml:01 intentional:01 expansions:01 flattening:01 equality:01 equality:01 wrote:01 dynamically:01 compile:01 slower:01 slower:01 The only times where I have used intensional equality (which was in a dynamically typed system for doing mathematics), it would have considered the bottom two lambda-expressions to be _different_, as in SML/NJ. This intensional equality is only used for optimizations. A function can optimize some cases based on intensional equality with some known cases, and fall-through to a slower general case otherwise. Not recognizing two terms as equivalent only results in slower computation time, not an incorrect result. You might see it as a sort of overloading based on function-level matching. Maple, Mathematica and MuPAD (internally) use this kind of dispatch-on-function feature a lot. This is related to the issue that in all these languages, 'constructors' and 'functions' are one and the same. My experience is that in practice, this works. Perhaps it would not be as useful in languages where constructors and functions are different. Jacques Stefan Monnier wrote: > I don't know what the OCaml optimizer may do, but I do know that in SML/NJ > such an intentional equality would often not give the expected result, > because it's pretty common for it to use various forms of eta-like > expansions in the hope of doing uncurrying or argument flattening, so you > may end up with > > f == f > > turned into > > (λx1.λx2.f(x1,x2)) == (λy1.λy2.f(y1,y2)) > > and the system may not try to recognize that the two lambda-expressions are > identical (too costly an analysis for no performance benefit), so it will > compile them to two different pieces of machine language. > > > Stefan > >