Python syntax in Lisp and Scheme

[Alexander Schmolck]

prunesquallor at comcast.net writes:
> 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.

Sorry, I have difficulties understanding what exactly you mean again. Would
you mind cutting and pasting something like the THEN/ELSE in the examples
below (say just marking the cut region with {}s and and where you'd like to
paste with @)?

(if CONDITION
    THEN
  ELSE)

if CONDITION:
   THEN
else:
   ELSE

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

You got it backwards. 
Not forgetting to press 'M-C-\' = programmer discipline.
Laxness at this point is a source of errors. 

And indeed, people *do* have to be educated not to be lax when editing lisp -
newbies frequently get told in c.l.l or c.l.s that they should have reindented
their code because then they would have seen that they got their parens mixed
up.

OTOH, if you make an edit in python the result of this edit is immediately
obvious -- no mismatch between what you think it means and what your computer
thinks it means and thus no (extra) programmer discipline required.

Of course you need *some* basic level of discipline to not screw up your
source code when making edits -- but for all I can see at the moment (and know
from personal experience) it is *less* than what's required when you edit lisp
(I have provided a suggested way to edit this particular example in emacs for
python in my previous post -- you haven't provided an analoguous editing
operation for lisp with an explanation why it would be less error-prone)).


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

No, I didn't want just *any* example of something that can't be displayed; I
wanted an example of something that can't be displayed and is *pertinent* to
our discussion (based on the Quinean assumption that you wouldn't have brought
up "things that can't be displayed" if they were completely besides the
point).

me:
> >> > People can't "read" '))))))))'.
[more dialog snipped]
> 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.

Well the version of SICM *I've* seen predeominantly seems to use (infixy) math
notation, so maybe Sussman is a little less confident in the perspicuousness
of his brainchild than you (also cf. Iverson)?

> Apparently he felt that not only *could* people read ')))))))', but
> that it was often *clearer* than the traditional notation.

Uhm, maybe we've got an different interpretation of 'read'?

If by 'read' you mean 'could hypothetically decipher', then yeah, sure with
enough effort and allowable margin of error, people can indeed 'read'
')))))))' and know that it amounts to 7 parens, and with even higher effort
and error margins they should even be able to figure out what each ')'
corresponds to.

I'm equally confident that you'd be in principle capable of 'deciphering' a
printout of my message in rot-13, modulo some errors.

I nontheless suspect I might hear complaints from you along the lines that
"couldn't read that" (if you had some reason to expect that its contents would
be of value to you in the first place).

I'm also pretty sure if I gave you version with each line accompagnied by its
rot-13 equivalent (and told you so) you'd just try to read the alphabetical
lines and ignore the rot-13 as noise (even if I told you that the rot-13 is
really the canonical version and the interspersed lines are just there for
visual convenience).

Now it's pretty much exactly the same for lisp code and trailing parens -- any
sane person in a normal setting will just try to ignore them as best as she
can and go by indentation instead -- despite the fact that doing so risks
misinterpreting the code, because the correspondence between parens and
indentation is unenforced and exists purely by convention (and lispers even
tend to have slightly different conventions, e.g. IF in CL/scheme) and C-M-\.

Reading *to me* means extracting the significant information from some written
representation and the ability to read is to do so with a reasonable amount of
effort. So in my diction, if a certain aspect of a written representation is
systematically and universally ignored by readers (at their peril) then surely
this aspect is unlikely to get points of maximum readability and one might
even conclude that people can't read so-and-so?

I don't personally think (properly formated) lisp reads that badly at all
(compared to say C++ or java) and you sure got the word-seperators right. But
to claim that using lisp-style parens are in better conformance with the
dictum above than python-style indentation frankly strikes me as a bit silly
(whatever other strengths and weaknesses these respective syntaxes might
have).


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

(Hmm, you or emacs?)
 
> 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?

Excellent point. But -- wait! Were it Lisp, how would I know that you didn't
intend e.g.

  (if (bar watz) foo)

instead of 

  (if (bar) watz foo)

?

Like in so many fields of human endeavor, XML provides THE solution:

 <if><bar/>watz foo</if>

So maybe we should both switch to waterlang, eh? 


Moral: I really think your (stereoptypical) argument that the possibility of
inconsistency between "user interpretation" and "machine interpretation" of a
certain syntax is a feature (because it introduces redundancy that can can be
used for error detection) requires a bit more work.


'as

p.s:

[oh, just to demonstrate that large groups of trailing parens actually do
occur and that, as has been  mentioned, even perl has its uses]:

 /usr/share/emacs/> perl -ne '$count++ if m/\){7}/; END{print "$count\n";}' **/*el
 2008