On Nov 17, 7:43 am, "Howard Lewis Ship" <[EMAIL PROTECTED]> wrote: > I generally like that Clojure dispenses with parens that exist for the > benefit of the evaluator rather than the developer; thus far fewer > parens when using (cond). Still, my old Lisp habits (20 years without > use) succumbed as much as Simons. See my earlier thread about > exception reporting. > > Could Clojure display errors like "seems like you're coding up some > Common Lisp here"?
C'mon, guys. There are no excess params in COND, COND is regular. (COND (condition value) (condition value) ... (condition value)) It's like that for good reason, and it's been like that since LISP 1.5 [1]. A programming construct which has remained unchanged for fifty years is almost certainly unchanged because it works. This is different from changing 'CAR' and 'CDR' to 'first' and 'rest' - our computers no longer have decrement registers, so calling an important function 'contents of the decrement register' is at best a geeky joke, at worst obscurantism. I'll continue to prefer CAR and CDR because I'm of that generation and that's what I'm used to, but it's unimportant. Replacing the word 'lambda' with 'fn' bothers me more. 'Lambda' isn't a piece of obscure history like CAR or CDR. It's a reminder that we're implementing - however imperfectly - the lambda calculus. The regularity of the language, however, is very important. If you want a separate macro called IF then I have no objection - I shan't use it so it doesn't worry me. But don't mess with COND! Having said that my initial performance tests this morning impress me. Factorial 1000 is a pretty poor test of overall performance but it's one I've used for twenty-five years and it's still always the first one I try. So Clojure: user=> (time (fact 1000)) "Elapsed time: 25.418373 msecs" Armed Bear Common Lisp: CL-USER(2): (time (fact 1000)) 0.093 seconds real time 3998 cons cells JScheme : fails to compute, fails to report an error! CMUCL (non-JVM): * (time (fact 1000)) ; Compiling LAMBDA NIL: ; Compiling Top-Level Form: ; Evaluation took: ; 0.02 seconds of real time ; 0.012 seconds of user run time ; 0.0 seconds of system run time ; 18,716,873 CPU cycles ; 0 page faults and ; 686,080 bytes consed. Java [2] : 0.071 seconds elapsed Now, this needs to be taken with a pinch of salt because I've timed only a few runs with each system, and haven't formally averaged - the above figures are typical figures for each system rather than strictly averaged ones. GC could potentially throw the figures way out on any of these systems. Nevertheless, what's interesting here is that Clojure is nearly four times faster than Armed Bear, and three times as fast as a (not exactly comparable) Java implementation. Clojure is even reasonably competitive with CMUCL, which seems to me very impressive. It would be interesting (and in the next few days I may) code up some of the benchmarks from http://shootout.alioth.debian.org/ in Clojure and see how they compare against Java, ABCL and SBCL. [1] Lisp 1.5 Programmers Manual, page 10, section 1.6; First published 1958. [2] Java 6 in its default form can't compute factorial 1000 recursively because it runs out of stack, and clearly doesn't optimise out the tail recursion - so you have to code it as iterative explicitly. Java also can't move transparently between integers and 'BigIntegers', so you have to code that explicitly as well. The Java implementation I used was: public BigInteger bigFact( BigInteger n) { BigInteger value = BigInteger.ONE; for ( BigInteger i = BigInteger.ONE; i.compareTo(n) < 0; i = i.add (BigInteger.ONE)) { value = value.multiply(i); } return value; } --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
