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=1.1 required=5.0 tests=AWL,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 EAE3ABC0A for ; Thu, 18 Jan 2007 13:23:03 +0100 (CET) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0ICN3Dx031509 for ; Thu, 18 Jan 2007 13:23:03 +0100 Received: by ug-out-1314.google.com with SMTP id q2so178868uge for ; Thu, 18 Jan 2007 04:23:03 -0800 (PST) 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=iSvLxXw1dCNSwkl9Hb1y6mJSFBtbRDw9v/LW+dSM87fbg3WCplBNryVBA0HxMeZiYv6OjL334OeSDqHRipOiP33lfJKrT98Tdz0Yu5l8rPDd97341qPIrfOorOEc48MODa4byHkxW98IBkm34uoEJOF2KbwocbPjLPQPHnAbKzY= Received: by 10.82.152.16 with SMTP id z16mr159697bud.1169122982864; Thu, 18 Jan 2007 04:23:02 -0800 (PST) Received: by 10.82.100.16 with HTTP; Thu, 18 Jan 2007 04:23:02 -0800 (PST) Message-ID: Date: Thu, 18 Jan 2007 13:23:02 +0100 From: Tom To: "Jacques Garrigue" Subject: Re: [Caml-list] Polymorphic Variants Cc: caml-list@yquem.inria.fr In-Reply-To: <20070118.102808.108741650.garrigue@math.nagoya-u.ac.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_175953_10122373.1169122982683" References: <20070117.111927.2004173151.garrigue@math.nagoya-u.ac.jp> <20070118.102808.108741650.garrigue@math.nagoya-u.ac.jp> X-j-chkmail-Score: MSGID : 45AF66A7.001 on discorde : j-chkmail score : XXX : 5/20 1 0.000 -> 3 X-Miltered: at discorde with ID 45AF66A7.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; variants:01 semantics:01 runtime:01 compile-time:01 overloading:01 runtime:01 subtyping:01 -like:01 semantics:01 inference:01 overloading:01 annotations:01 ambiguities:01 ambiguities:01 subtyping:01 X-Attachments: cset="UTF-8" cset="UTF-8" ------=_Part_175953_10122373.1169122982683 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > Both reasons have practical impact. For the first one, using erasure > semantics means that the programmer also can discard types when > understanding the runtime behaviour of a program. Actually, what I had in mind is exclusivelly compile-time overloading, which causes no overheed at runtime. > > Hm... Actually, what I had in mind is nominal subtyping... similar to > > objects, in fact, objects in C++-like languages, just that they have no > > class methods. > > Reading the description below, this all looks nice, independently of > the semantics limitation described above. However, you can kiss > farewell to type inference. With such an extensive overloading, you > would need type annotations all over the place. > For the second one, > you can write code that is maximally polymorphic, without too much > fear about the impact of performance (equality is overloaded, so > it still matters...) or strange ambiguity-related error messages. I believe that "strange ambiguity-related error messages" are the result of stupid programmers, not of the language. If one is careful to design a sane library, most ambiguities never happen! Besides, incorporating whole-program analysis (in the spirit of MLton), one can postpone such errors until the whole application has been written, so for example local ambiguities would be resolved by examining the uses (if a function is always called with arguments of single type, there is no ambiguity). > Not for records, but for objects. From a type-theoretic point of view > they are just equivalent. > By the way, this all looks likes the "used this feature in C++" > syndrome. Sure C++ is incredibly powerful. But it is built on rather > shaky theoretical fundations. So you can't expect to bring everything > from C++ to a new language. Why not think about new ways to solve > problems :-) Well, I am... but just as you are in your message mentioning the practical impact, so am I. And I think that every way to implement subtyping of records/objects (=named tuples) other than the C++ way has an important practical consequence - it's just slow. I guess that C++ like index-based access is much faster than name-based access neccessary for structural subtyping. Thou, please prove me that I am wrong :) I want structural subtyping, the OCaml way, just very fast. - Tom ------=_Part_175953_10122373.1169122982683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 

 
Both reasons have practical impact. For the first one, using erasure
semantics means that the programmer also can discard types when
understanding the runtime behaviour of a program.
 
Actually, what I had in mind is exclusivelly compile-time overloading, which causes no overheed at runtime.
 

 
> Hm... Actually, what I had in mind is nominal subtyping... similar to
> objects, in fact, objects in C++-like languages, just that they have no
> class methods.

Reading the description below, this all looks nice, independently of
the semantics limitation described above. However, you can kiss
farewell to type inference. With such an extensive overloading, you
would need type annotations all over the place.

For the second one,
you can write code that is maximally polymorphic, without too much
fear about the impact of performance (equality is overloaded, so
it still matters...) or strange ambiguity-related error messages.
 
 
I believe that "strange ambiguity-related error messages" are the result of stupid programmers, not of the language. If one is careful to design a sane library, most ambiguities never happen! Besides, incorporating whole-program analysis (in the spirit of MLton), one can postpone such errors until the whole application has been written, so for example local ambiguities would be resolved by examining the uses (if a function is always called with arguments of single type, there is no ambiguity).
 
Not for records, but for objects. From a type-theoretic point of view
they are just equivalent.
 

 
By the way, this all looks likes the "used this feature in C++"
syndrome. Sure C++ is incredibly powerful. But it is built on rather
shaky theoretical fundations. So you can't expect to bring everything
from C++ to a new language. Why not think about new ways to solve
problems :-)
 
Well, I am... but just as you are in your message mentioning the practical impact, so am I. And I think that every way to implement subtyping of records/objects (=named tuples) other than the C++ way has an important practical consequence - it's just slow. I guess that C++ like index-based access is much faster than name-based access neccessary for structural subtyping. Thou, please prove me that I am wrong :) I want structural subtyping, the OCaml way, just very fast.
 
- Tom
------=_Part_175953_10122373.1169122982683--