Python syntax in Lisp and Scheme

[Joe Marshall]

"Terry Reedy" <tjreedy at udel.edu> writes:

> However, the recent spate of garbage-dumping has lead me to question
> whether I should even look at CL.  It seems that c.l.lisp would not
> be a friendly place to ask questions.

I'll apologize for the posts of mine that drifted over into
comp.lang.python  they were unintentional.

We're not deliberately unfriendly here in c.l.l, but about once or
twice a month someone comes into the group and makes claims about the
illegibility of parenthesis.  We do get tired of this.

Of course it is as unreasonable to bitch and moan to python people
about whitespace in comp.lang.python.  I've haven't intentionally
started any arguments in comp.lang.python about it, but I'm afraid
that I haven't been as vigilant in watching the followups as I should
have been.

> If you look more carefully at both my paragraph and the one near the
> top copied from Mr. prunesquallor's post, you might discover that
> 'whitespace', a programming term dating back 30 years old or more,
> occurs in a phrase quoted from Mr. P's post.  So ask him.

Whitespace in Lisp is defined as 

  whitespace n. 1. one or more characters that are either the graphic
  character #\Space or else non-graphic characters such as #\Newline
  that only move the print position. 2. a. n. the syntax type of a
  character that is a token separator. b. adj. (of a character) having
  the whitespace[2a] syntax type[2]. c. n. a whitespace[2b] character.

Other non-graphic characters usually include #\Tab, #\Form, #\Return,
#\Linefeed, and sometimes #\VT and #\NUL.

>> Removing white-space from (1 2 3) gives me (123).  I agree, very
> different,
>
> Which is exactly my point.  Thank you for agreeing.  This supports the
> main point of my post, which is that attacking Python for having
> critical whitespace is logically also an attack on Lisp for the same
> reason.

I was being imprecise.  Since Python treats intertoken whitespace
essentially the same as Lisp, there is no logical argument that can
include one and exclude the other.  My concern revolves around
delineating code blocks through creating common prefixes on the
associated lines, *and* that these prefixes are hard to see (although
it is *not* hard to see that they exist, nor hard to see if two
adjacent ones are the same or different, but that it *is* hard to see
exactly how many of them are there in deeply indented code). 


I'll remove further followups to comp.lang.python