Python syntax in Lisp and Scheme

[Alexander Schmolck]

[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.
 
> Also, it is frequently the case that you need to `tweak' the code after
> you paste it.

Sure, but I don't generally feel that tweaking python code in emacs is
particularly inconvenient (it is not always as convenient as tweaking lisp
code, which is partly due to the fact that essentially there isn't any proper
implementation of the sexp commands for non-lisp modes; OTOH some operations
are more convenient).

> You misunderstand me.  In a python block, two expressions are
> associated with each other if they are the same distance from the left
> edge.  This is isomorphic to having a nametag identifying the scope
> of the line.  Lines are associated with each other iff they have the
> same nametag.  Change one, and all must change.

Hardly a problem with a decent editor (and surely less of a problem even with
the proverbial notepad than getting the closing paren in the right spot and
reindenting everything).

> because the grouping information is replicated on each line, I have to
> fix this information in the six different places it is encoded:

Why, for example, not just first insert the new if statement and then run an
editor command that indents all the following lines up to the same indent
level one further indent level? To me this wouldn't seem to me have
intrisically more room for screw-ups than inserting a '(WHEN' and an
additional ')'.

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

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

 
> >> 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? Apart from the fact that only leading whitespace is
significant in python, I've personally never felt any need to count it -- have
you? I have, however felt the need to count parens from time to time (in
python as well).

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

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?

Anyway, readability is an overarching but not the only important factor in the
design of language's syntax (you mentioned the ergonomics of editing and there
are of course others), and as I said I think sexps are in fact a rather good
syntax for an expression oriented language.

'as