Python's Lisp heritage

[James J. Besemer]

Paul Foley wrote:

> I think you're missing the point: Lisp is not defined in terms of
> text; instead, it's the objects that result from calling READ on that
> text.  There are no parentheses in that result; there are only lists,
> symbols, strings, integers, etc., etc.  That's why you can define
> things like the infix syntax reader Jacek Generowicz mentioned.
>
> READ can call arbitrary user-defined functions to parse the textual
> representation into internal objects, so it can read any surface
> syntax you want.

I appreciate that Lisp can be customized to process any alternative input that you like.  And
that the default S-expression notation may be abstracted away from the underlying language
semantics.

However, seems to me that out of the box there is this default S-expression notation that is
rather pervasive to programming in Lisp.  If you pick up a book on a particular dialect of
Lisp or a manual on a particular implementation they all begin with this same default syntax.
This default notation, it seems to me and many others, requires more parentheses than you
normally have occasion to use in Algol-like languages such as Pascal, C or Python.

Although I personally did not find these differences to be a problem when I used to program in
Lisp I sympathize with those who find them strange and unfamiliar.  I feel the default
S-expression syntax represent a legitimate barrier to entry, however slight, to new people
approaching and learning the language for the first time.

You and others obviously do not agree.

So be it.

Regards

--jb

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