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 BAA09737; Fri, 25 Jun 2004 01:02:41 +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 BAA10626 for ; Fri, 25 Jun 2004 01:02:39 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5ON2cSH024314 for ; Fri, 25 Jun 2004 01:02:38 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i5ON2Ui13151; Thu, 24 Jun 2004 18:02:31 -0500 (CDT) Date: Thu, 24 Jun 2004 18:08:27 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: John Hughes cc: "'caml-list'" Subject: RE: [Caml-list] Why must types be always defined at the top level? In-Reply-To: <20040624142732.9767110EF06@clark.cs.brown.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 40DB5D8E.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 printf:01 semicolon:01 printf:01 semicolons:01 3.07:01 ignoring:01 infinities:01 slower:01 floats:01 demonstrate:01 debug:01 ocaml:01 ocaml:01 caml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 24 Jun 2004, John Hughes wrote: > > 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; ? Let doesn't need them- there are a lot of other places where Ocaml could use disambiguation. Basically, I'm a beleiver that if there is a shift-reduce conflict in the obvious implementation of the grammar, there is a problem the programmer is going to trip over. One big one- I wish if was ended with an endif or similiar. How many times have you accidentally coded something like: if x > 3 then printf "x = %d\n" x; x - 3 else x + 1 This is especially common when, like in my example, you're dropping in debug print statements. Unfortunately, the semicolon at the end of the printf statement also ends the if statement. > > 3. Why semicolons for separating list items, so that > > [2,3] is interpreted as [(2,3)] ? How would I make a list of one element of type int * int? > > 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)? sqrt(2.);; Mathematicians don't have a problem with dealing with an infinite number of decimal places. Computers do. You can hide some of the problems- at great cost in terms of performance and memory- but sooner or later you're going to deal with precision loss. $ ocaml Objective Caml version 3.07 # 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1 +. 0.1;; - : float = 0.999999999999999889 Plus, all the comments I made about integers apply, and then some. Hardware based floating point is much faster than any software based floating point (even ignoring the infinities and nan problems). Going to software base FP is easily 10x slower than hardware, possible (probably) more. And doesn't really save you much of anything. This is just pointing up, to me, why there is a difference between a teaching language and a production language. As something looking at using Ocaml as a production language, I am opposed to even adding overflow detection on ints- in the few, minor places I need it, I'll either use larger integers, or I'll add in explicit checks myself. But don't slow down even a little the vast majority of my integer operations. This goes at least double for my floating point operations. For a teaching language, I'd definately include integer overflow detection at the least, and would seriously consider making integers arbitrary precision. I'd also strongly consider making floats software, but not so that I could increase precision, but so that I could decrease precision- numerical instability is a lot easier to demonstrate if you only have four digits of precision, and not 15. But, then again, performance isn't a concern with a production language. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- 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