Python's Lisp heritage

[James J. Besemer]

Paul Foley wrote:

> No I don't have to admit that...I don't even have to admit that there
> are any parentheses in Lisp :-)

What color is the sky in your world?  ;o)

Seriously, I agree, the underlying abstraction -- the semantics -- does not require
parentheses.  But that's not really the language, per se.  I'm of the school that a
particular language, curly-L, consists of a tuple: ( Syntax x Semantics ).  Of course you
may change one component one and not the other but each change nevertheless results in a
distinct language.

I have seen "editors" that allow you to edit control structures in a purely graphical
form.  There was a 1:1 correspondence with a subset of the target language.  But to me the
graphical form really is is a different language or at least a different syntax for a
language, not the original language, like "RatFor" is to Fortran.

I agree, a proper editor can be a big help.  Ordinary VI's lisp mode is not bad, and
although in this case the parens could not be omitted, it allows you largely ignore them.
Still, you "have" to agree that most people's exposure is through the ascii
representation, in which case I think it's hard to argue parentheses not an intrinsic part
of the language (if "only" syntax).

That's why I like Python, as it provides access to a lot of the same functionality as Lisp
in a more familiar syntax, without all the tedious punctuation.

> In any case, parentheses are not used around sub-expressions, or to
> separate or group statements.  They're only used (in evaluated
> contexts) for "function" calls, and most other languages, including
> Python, use parentheses for that purpose, too:
>
>  Python: foo(x)
>  Lisp: (foo x)
>
> Same number of parentheses, right?

Besides, this is an entirely contrived, intellectually dishonest example.

First off, parens ARE used around sub expressions last I checked, unless I don't get how
you define sub expression.  E.g.,

    (foo (+ x (/ 1 n)))

vs.

    foo( x + 1 / n ).

So now compare

        if x > y or a = 0:
            a1 = m * x + b
        else:
            a2 = m / x - b

with

        (if (or (> x y ) (zerop a))
            (setq a1 (+ (* m x ) b )
            (setq a2 (- (/ m x ) b )).

In this case, Lisp requires about 33% more typing, almost all parentheses.

And, oh yeah, I forgot, aside from the parentheses, the pervasive prefix notation can be a
drag.  And I'm the type that still finds HP's stack notation less confusing in a
calculator than infix.  But having to mentally convert everything back and forth between
infix and prefix notation also can make you nuts.

That being said, I acknowledge that arithmetic is a small part of some large systems and
once you rise above the lower levels of abstraction, "everything" is function (or member)
calls, and your original example begins to be more valid.  Still, arithmetic crops up and
awful lot even then and can confound even the most enthusiastic programmer.

> 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.

> ? prefer controlling the semantics with an "Algol-like" syntax.
>
> Which is also possible in Lisp, of course; in fact, Lisp was
> originally intended to have an "Algol-like" syntax (McCarthy's
> M-expressions) on top of S expressions...

I'm not sure they're the same thing.

> ?? [And it's worth noting that, as with other aspects of Lisp, people
> ?? just keep reinventing it, badly --
>
> ? Hmmm.... I was recently accused of making this claim, which is entirely untrue.
>
> Eh?  What's untrue?  The claim or that you made it?

I only deny that I ever made the claim.

Interesting discussion.

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com