From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA28952; Thu, 24 Jun 2004 19:45:56 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA28877 for ; Thu, 24 Jun 2004 19:45:55 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5OHjsSH018686; Thu, 24 Jun 2004 19:45:54 +0200 Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA28827; Thu, 24 Jun 2004 19:45:53 +0200 (MET DST) Date: Thu, 24 Jun 2004 19:45:53 +0200 From: Xavier Leroy To: John Hughes Cc: "'caml-list'" Subject: Re: [Caml-list] Why must types be always defined at the top level? Message-ID: <20040624194553.A27745@pauillac.inria.fr> References: <1088023950.1941.98.camel@pelican.wigram> <20040624142732.9767110EF06@clark.cs.brown.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20040624142732.9767110EF06@clark.cs.brown.edu>; from jfh@cs.brown.edu on Thu, Jun 24, 2004 at 04:27:38PM +0200 X-Miltered: at concorde with ID 40DB1352.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 checker:01 haskell:01 sml's:01 gratuitous:01 semicolons:01 semicolon:01 reals:01 floats:01 reals:01 floats:01 reinvent:01 kahan:01 abide:01 arrays:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 1. Why no eqtypes? The idea of having the type-checker verify that you > weren't doing equality testing on non-equality-testable types seemed > like GOOD thing in SML, and I was surprised to see it gone. Eqtypes have been hotly debated even among the SML designers. My feeling is that it's not worthwhile to have a special, hard-wired mechanism in the type checker just for the sake of equality. There is a general need to have polymorphic operations that are 1- not defined on all instantiations of their types, and 2- can be defined differently on different instantiations. Haskell type classes are an example of a *general* mechanism that addresses this need; GCaml's "extentional polymorphism" is another. But SML's eqtypes are just not general at all. > 2. Why no "end" on "let" expressions, i.e., > > let a = 3 and b = 2 in a + b;; > > rather than > > let a = 3 and b = 2 in a + b end; ? Ah, syntax... Without entering in a debate on which syntax is "better", let me just give an historical reason: there was no "end" on "let" expressions in the original LCF ML, from which Le_ML, then the first Caml, then Caml Light, then OCaml derive. We don't like gratuitous syntax changes :-) > 3. Why semicolons for separating list items, so that > > [2,3] is interpreted as [(2,3)] ? Why not? Again, I guess this is historical. Both SML and the various Camls use two symbols "," and ";" to denote three different things (tuples, lists and arrays, and sequence). SML "overloads" the comma to mean two of these things, Caml overloads the semicolon. > 4. Why expose the hardware with float (and make it have equality > testing) rather than continue with "real" (which was not an eqtype, if > I recally correctly)? Unless a language offers exact-precision arithmetic on computable reals, I strongly object to the use of the word "real" to refer to what's merely floating-point numbers. Floats aren't reals by any stretch of the imagination, and the earlier the programmer realizes this, the better. As to whether equality should be defined on floats, there are pros and cons. My standpoint is that it's eventually better to stick to established standards (that is, IEEE float arithmetic) rather than try to reinvent a wheel likely to be even squarer than these standards. Prof. Kahan found it worthwhile to fully define equality over floats; I'll abide by his wisdom. - Xavier ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners