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 VAA02047; Thu, 24 Jun 2004 21:46:26 +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 VAA02069; Thu, 24 Jun 2004 21:46:25 +0200 (MET DST) Received: from salt.cs.brown.edu (salt-dmz.cs.brown.edu [128.148.32.122]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5OJkOSH000812; Thu, 24 Jun 2004 21:46:24 +0200 Received: from localhost (localhost [127.0.0.1]) by salt.cs.brown.edu (Postfix) with ESMTP id 8E883D8737; Thu, 24 Jun 2004 15:46:05 -0400 (EDT) Received: from salt.cs.brown.edu ([127.0.0.1]) by localhost (salt [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16268-09; Thu, 24 Jun 2004 15:46:05 -0400 (EDT) Received: from null.cs.brown.edu (null.cs.brown.edu [128.148.38.190]) by salt.cs.brown.edu (Postfix) with ESMTP id 33B9AD86F7; Thu, 24 Jun 2004 15:46:05 -0400 (EDT) Received: from clark.cs.brown.edu (clark [128.148.31.45]) by null.cs.brown.edu (Postfix) with ESMTP id B78503CAA; Thu, 24 Jun 2004 15:46:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by clark.cs.brown.edu (Postfix) with ESMTP id 4B9C110EF0D; Thu, 24 Jun 2004 15:46:04 -0400 (EDT) Received: from clark.cs.brown.edu ([127.0.0.1]) by localhost (clark [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00234-10; Thu, 24 Jun 2004 15:46:04 -0400 (EDT) Received: from spikeshomepc (meylan-1-82-225-49-106.fbx.proxad.net [82.225.49.106]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by clark.cs.brown.edu (Postfix) with ESMTP id 2A91010EF06; Thu, 24 Jun 2004 15:46:03 -0400 (EDT) Reply-To: From: "John Hughes" To: "'Xavier Leroy'" Cc: "'caml-list'" Subject: RE: [Caml-list] Why must types be always defined at the top level? Date: Thu, 24 Jun 2004 21:46:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040624194553.A27745@pauillac.inria.fr> Thread-Index: AcRaExn7w9g992MFQXmhtloydkjIDgADw+iA Message-Id: <20040624194603.2A91010EF06@clark.cs.brown.edu> X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at cs.brown.edu X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at cs.brown.edu X-Miltered: at concorde with ID 40DB2F90.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 semicolons:01 reals:01 floats:01 reals:01 kahan:01 cryptic:01 invoke:01 ints:01 equality:01 int:01 int:01 arithmetic:01 arithmetic:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Thanks for the answers. > > 1. Why no eqtypes? > > 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. Agreed. One of our students, a year ago, after being told about eqtypes, asked "is there something like 'numtype' too, so that we can tell whether it's OK to do arithmetic?" (Recall this was SML, where "+" is overloaded.) It was clear that the idea *behind* eqtypes should be extended ... but the alternative, of removing them entirely, is just as consistent, I suppose. > > 2. Why no "end" on "let" expressions, i.e., > [History] > > > 3. Why semicolons for separating list items, so that > > > > [2,3] is interpreted as [(2,3)] ? > > [Why not?] Fair enough. > > 4. Why expose the hardware with "float" ... > > 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. This from someone who uses "int" to mean something other than "integer"! :-) > Floats aren't reals by any stretch of the imagination, and > the earlier the programmer realizes this, the better. Agreed. And deference to Bill Kahan is generally a good idea. --- I have one more question, though: 5. Why can I no longer type-annotate things I've written, so that let f x y z = (x = y) & (y = z) defines a function applicable to ALL types? I actually *liked* being able to say something like let f x y z:int = (x = y) && (y = z) so that it would be restricted to ints. (It frequently helped me to untangle cryptic error messages that ML produced, AND to document my intent as I wrote code). I can still trick it into doing that, by something like let f = function | (x,y,z) -> (x==y) && (y == z) | (a,b,_) -> (a-b) = 0;; which will turn out to never invoke the second case, but still restrict the type. But surely this is not more readable/maintainable code...(Yes, I know it has a slightly different signature, but I didn't have the heart to work around that just now). Thanks again for the informative answers. -John Hughes ------------------- 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