Python's Lisp heritage

[Jacek Generowicz]

"James J. Besemer" <jb at cascade-sys.com> writes:

> Jacek Generowicz wrote:
> 
> > No, as Paul said, they are used for "function calls". Admittedly,
> > in mathematical expressions function call often coincide with
> > sub-expressions, but it does depend on the sub-expression in
> > question.
> 
> Thanks for the clarification.  Now I get it.
> 
> > Compare
> >
> >    (+ 1 2 3 4 5 6 7 8 9 10)
> >
> > with
> >
> >    1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10
> >
> > Gosh, what a lot of typing I have to do in Python, compared to lisp.
> 
> So that begs the question: is it more common to have lengthy "sub
> expressions" like your example or is my example with a mixture of
> operations more typical?

My example was only half serious. (Well, three-quarters serious <0.75 wink>)

> > But, if you are dealing with mathematical expressions, then,
> > obviously, you will use some sort of infix notation macro:
> 
> I am not familiar with Common Lisp and did not know that was common.

I'm not sure what this has to do with _Common_ Lisp in particular.

I see it a bit like like criticizing python, for example, for not
allowing you to build a usefully fast matrix class, while completely
ignoring the existence of Numpy.

> Though I suppose I should have guessed that anything's possible.

Now you're talking :-)

Actually, if you are not familiar with lisp macros, then you may well
be very surprised by just how far "anything" goes in this case.

> > Incidentally, it would be interesting to see how many people would
> > correctly work out in their heads (on first attempt) what
> > 1+2*3/4-5 evaluates to (leaving aside the fact that in Python it
> > evaluates to -3[*]) . . . and then compare it to the success rate
> > when considering the equivalent (+ 1 (/ (* 2 3) 4) -5). Or maybe
> > how long it takes them to get the right answer in each case.
> 
> Hard to say.  Do the survey and lemme know.
> 
> Then too, this is a simple example and it seems the big trick in
> either case is in knowing how divide works.
> 
> In Python's case it's truly a trick question as there presently is
> absolutely no way to predict what the result will be without several
> bits of additional information.  (I came late to the argument, but
> personally I think so called "true division" is/was a big mistake.)

I specifically mentioned that I wanted to leave aside consideration of
python's answer to this, because the point I was trying to make was
that it seems to me that _I_ can work out (+ 1 (/ (* 2 3) 4) -5) more
easily (at first blush) than 1+2*3/4-5, which surprised me (just a
little), given that I had just argued (in agreement with you) that (in
general) the latter is probably easier for mathematical expressions.

> Then too, the results probably vary among Lisp implementations, so
> you'd have to be more specific in that case too.  IIRC, some systems
> were integer only, some were real only and some had both numeric
> types.  I dunno what's standard these days.

I'm not sure what you mean. I'm no expert on the features of various
lisp implementations in history. ANSI Common Lisp (which was
standardized around the time python was born IIRC) is what I would
guess most lisp users use these days (elisp has a very specific
domain), has a plethora of numeric types including unlimited size
integers, rationals and complex numbers.

All ANSI CL compliant implementations will agree.

> So I guess the "trick" parts of the question would far outweigh any
> data about infix vs. postfix.

Which is exactly why I was trying to steer the conversation clear of
the trick parts. What I had in mind was:

1) Ensure that the guinea pig (gp) understands the meaning of the
   mathematical operators.

2) Ensure that gp understands both prefix and infix notation.

3) Show gp one of the expressios written down on a piece of paper.

4) Note the time taken for gp to produce the correct answer.

By "correct answer" I mean any of -5/2, -2.5, "minus two and a half",
"the negative square root of six and a quarter", etc., but most
certainly _not_ -3 or -2.

5) Repeat for many different gps with different expressions.

> > > > I'd expect Lisp syntax to be rather less error-prone, if
> > > > anything, since it's much simpler
> > >
> > > I think that's debatable.  Certainly simplicity makes it easier
> > > to learn, so that's a plus.  But it's still very tedious to get
> > > all the parentheses matched up just right.
> >
> > It seems that many (most?) people who actually try to write lisp
> > without making a big issue of the parentheses, very rapidly come
> > to a conclusion that disagrees with yours.
> 
> 1. I think that's a fair statement.  Earlier in the week, someone
> suggested I'd be more happy with Python after I was "reprogrammed"
> to think "Pythonically"

I think it is generally true that embracing the features of a
language, rather that struggling against them and trying to make the
language fit the mindset one has picked up in other languages, is a
good thing. At least in the initial stages :-)

Cheers,