Python syntax in Lisp and Scheme

[prunesquallor at comcast.net]

Alexander Schmolck <a.schmolck at gmx.net> writes:

> [narrowing down to c.l.l and c.l.p]
> prunesquallor at comcast.net writes:
>
>> > Significantly, AFAICT you can easily do this unambiguously and *locally*,
>> > for example your editor can trivially perform this operation on cutting a
>> > piece of python code and its inverse on pasting (so that you only
>> > cut-and-paste the 'local' indentation). Prima facie I don't see how you
>> > loose any fine control.
>> 
>> Only if your cut boundaries are at the same lexical level.  If you cut
>> across boundaries, it is no longer clear what should happen at the paste.
>
> The only unclarity would arise from dedents of more than one level on the
> corner of your cut region, I think.

Suppose I cut just one arm of a conditional.  When I paste, it is
unclear whether I intend for the code after the paste to be part of
that arm, part of the else, or simply part of the same block.

>> The fact that the information is replicated, and that there is nothing
>> but programmer discipline keeping it consistent is a source of errors.
>
> Sure there is. Your editor and immediate visual feedback (no need to remember
> to reindent after making the semantic changes).

`immediate visual feedback' = programmer discipline
Laxness at this point is a source of errors.

>> > I don't understand why this is any different to e.g. ')))))' in Lisp. The
>> > closing ')' for DEFUN just looks the same as that for IF.
>> 
>> That is because the parenthesis *only* encode the grouping information,
>> they do not do double duty and encode what they are grouping.
>> The key here is to realize that the words `DEFUN' and the `IF' themselves
>> look very different.
>
> Well, I'm evidently still not getting it, because my reply would be "and so do
> 'def ...:' and 'if ...:' in python" (and you also can't tell whether the 8
> spaces on the left margin come from a 'def' and and an enclosed 'if' or vice
> versa).

I'm not sure I can explain any better, I *think* perhaps some of the other
Lispers might get what I'm saying here.

>> >> Yet the visual representation is not only identical between all of these, it
>> >> cannot even be displayed.
>> >
>> > I don't understand what you mean. Could you maybe give a concrete example of
>> > the information that can't be displayed? 
>> 
>> Sure.  Here are five parens )))))  How much whitespace is there here:          
>
> 10 spaces (which BTW I counted in emacs in just the same way that I'd count a
> similar number of parens) -- but what has counting random trailing whitespace
> got to do with anything? 

It is simply an illustration that there is no obvious glyph associated
with whitespace, and you wanted a concrete example of something that can't
be displayed.

>> > Still, I'm sure you're familiar with the following quote (with which I most
>> > heartily agree):
>> >
>> >  "[P]rograms must be written for people to read, and only incidentally for
>> >    machines to execute."
>> >
>> > People can't "read" '))))))))'.
>> 
>> Funny, the people you just quoted would disagree with you about parenthesis.
>> I expect that they would disagree with you about whitespace as well.
>
> Why, do they know someone with a paren-counting brain-implant? If so every
> lisper should get one -- no more carpal tunnel syndrome from frantic C-M-\
> pressing or alphabet wastage due to scheme-style 'aliasing' of '[...]' to
> '(...)'.
>
> Seriously, I really fail to see see what the source of disagreement with the
> above statement could be.

I cannot read Abelson and Sussman's minds, but neither of them are
ignorant of the vast variety of computer languages in the world.
Nonetheless, given the opportunity to choose any of them for
exposition, they have chosen lisp.  Sussman went so far as to
introduce lisp syntax into his book on classical mechanics.
Apparently he felt that not only *could* people read ')))))))', but
that it was often *clearer* than the traditional notation.

> If I gave you a piece of lisp code jotted down on paper that (as those
> hypothetical examples usually are) for some reason was of vital importance and
> that on typing it in revealed a mismatch between the indentation and the
> parenthesation in a key section of the code -- which interpretation would you
> hedge your bets on in the absence of other indicators; the one suggested by
> the indentation or the 9 trailing parens?

Obviously the indentation.  But I'd notice the mismatch.

If I gave you a piece of python code jotted down on paper that (as these
hypothetical examples usually are) for some reason was of vital importance
but I accidentally misplaced the indentation -- how would you know?