Re: [tlug] recomendations for a functional language

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > I'll admit I don't have a lot of experience writing Lisp
 > macros. (Now, M4 macros, that's another story. :-))

You can say that again.  Who needs Brainf*ck when you can program in M4?

 > On review, Clojure is certainly further from Common Lisp than I'd
 > thought in my last post (despite being a Lisp-1, and not a Lisp-2),

Being a Lisp-1 takes it quite far from Common Lisp, IMHO.

 > especially in its emphasis on recursion rather than looping (though I've
 > not examined how well it really does when it comes to guaranteeing tail
 > call optimization, which is an important point when using recursion in a
 > language compiled to the JVM).

It doesn't do any tail call optimization according to the website;
that's up to the programmer to use the loop ... recur syntax, or the
trampoline macro.

 > For Common Lisp versus Scheme, I'd summarize the differences as:
 > 
 >   * the Lisp-1 versus Lisp-2 distinction (which can itself be
 >   over-summarized as whether function variables and non-function
 >   variables share a namespace, but upon research it turns out to be a
 >   lot more subtle than that),

Again, CL is a Lisp-2 while Scheme is Lisp-1.

 >   * that Lisp tends heavily towards iteration and Scheme towards
 >   recursion,

I would disagree with that.  CL provides more facilities for iteration
than does Scheme, it's true, but the most commonly used are mapping
functions like mapcar and maplist, which are basically optimized tail
calls.  There's also horrible stuff like the loop macro, but we won't
describe that in polite company. :-)  Point is, design is often done
using recursion, then optimized to iteration.

 > Looking at Clojure, actually, it seems as if it might be one of the
 > best of the Lispy languages to learn, if you're going to go that
 > way.

I dunno.  Clojure seems to have a lot of practical but inelegant stuff
in it.  It might be useful in future "real work", but I'm not sure
it's a good way to learn about Lisp.

Re: using "inelegantly programmed" libraries for dealing with money:

 > That's reasonable. I once started into a ferocious argument about using
 > floating point for representing monetary values. There was, on some
 > forum somewhere, a poor soul with a PHP shopping cart who was worried
 > that it was using floating point to represent dollars, and perhaps
 > things like a 7% discount on the entire order wouldn't work out
 > well.

Did you point out that 90 trillion dollars is a pretty damn big order,
even for the United States federal government?  The point being that
even if my back-of-the-hand numerical analysis is bogus, a few minutes
with pencil and paper should convince one that this is not going to be
a problem.  The analysis can be done.  (OTOH, if PHP uses IEEE 754
singles, he could run into trouble if he's selling yachts or condos.)

I'm more worried about (say) the difficulty of adding a bit of memory
to the system so that (for example) if there's an error in the phone
number entered, the user gets presented with everything already filled
in *except* the phone number.  And keeping the phishermen out.