You can probably guess what I'll say here. It's hard to say "DON'T
CHANGE ANYTHING" in new and creative ways. Here are my comments on
Donald's proposal.
On the positive side, this proposal made an attempt to maintain backwards
compatibility with existing programs. Thanks for not trying to break
all my existing code. That was considerate of you.
Donald Beaudry writes:
> g> Fixing this latter anomaly would require an even larger barrage of
> g> rather similar grammar rules and corresponding code in compile.c.
> g> Contrast this to my "optional end clause" solution, which would
> g> require minimal changes, and has additional redundancy (a la Ada) as
> g> well ("end if", "end for", etc.).
>
> It's not an atrocity or an anomaly, it is a feature... we should give
> the typical Python programmer some credit here, not all of them are as
> incompetent as you suggest:), leave it up to them to use good taste
> when writing python code. A trap that I did not want to fall into was
> that of requiring an 'end' everywhere. I don't see a need for one
> after a single line 'else' clause. The main problem I have with my
> proposal is that it allows multiple statements after the colon, I
> would prefer just one.
It's not a matter of incompetence or bad taste, its a matter of
utility. Style and personal expression are fine when dressing for an
evening out, but they can interfere with productivity when others must
read your code. Consider the difficulty of reading a text book
written on computer programming in which each paragraph was written
with very different writing styles. Using varied literary styles may
be interesting or thought provoking but it is just a distraction if
you are scanning a text on on the language to find something
particular in the language. The proposal to change the syntax reduces
the utility of the syntax by eliminating a consistent style.
Python has made a small dent in this problem area and Guido continues
to be beat up by everyone who fails to see the value of this feature
of the language. The great thing about Python's style standard is
that it actually reduces the work required to express algorithms. The
minimalist design of the language has actually integrated style with
syntax so that style implements semantics. Stop trying to screw this
up!!
Your proposed syntax change adds nothing to the language beyond what
pindent can provide and it will make it harder for me to read your
software. Have you consider that some individuals may have vision
problems for which your "improved" syntax may make life significantly
harder? More characters on the screen make reading the code much
harder. The consistent placement of characters on the screen make it
possible to see the structure of the program without having to read
every character for structural clues.
> But, I am flexible... an alternative would be to disallow any
> colon-ized clauses as part of a complex statement that was started
> without a colon. This would have the effect of requiring that final
> 'end' in your second example.
>
> Also, I have no problem with following the 'end' with the keyword that
> opened the block. I didn't bother with it because it would have ment
> that the patch would have to enforce it as well. And that was more
> code than I cared to write.
>
> g> Don claims that an optional end clause is no more useful than an
> g> optional "# end" comment. This may be true, but does his solution
> g> have any more value? I doubt it. If the user provides correct
> g> indentation, a missing (or unexpected) end clause is immediately
> g> noted by the discrepancy in indentation. If the user cannot promise
> g> correct indentation, the only solution is to require end clauses
> g> everywhere in the file (as does my "pindent -r" script).
>
> It is not a matter of the user providing correct indentation, it has
> more to do with fixing up the indentation after a mad session of
> cut-n-paste programming.
If you've just finished a mad session of cut-n-paste programming, why
would running pindent -r on the file be an unrealistic expectation for
cleaning up your mess? Why does this language "feature" have to be
built in at the parser level? Why can't it be a tool in you toolbox
that you can use to verify that your code conforms to your style of
programming? Using pindent allows this to be done without destroying
the general rules of style of the Python language. You are asking
Guido and the rest of the world to adopt to your particular style of
programming rather than adopting your style to fit with the
methodology created by the existence of features in the Python language.
> g> Finally, what seems to me an unrelated matter:
>
> > But, a change that I would not mind seeing, which
> > would break existing code, would be to limit to one the number of
> > statements allowed after the colon. Making this additional change
> > would be as simple as it would be controversial, but making it would
> > pave the way for implementing a clean solution to the "multi-line
> > lambda problem" which was discussed previously.
>
> g> As I said previously, why stop at a multi-line lambda? A more
> g> "orthogonal" solution would be multi-line "valof" blocks as in BCPL!
> g> Anyway, I don't see how this would work -- hints, please?
>
> But who needs multi-line "valof" blocks when you have multi-line
> lambdas. The (not so obvious) point of my comment was that my
> previous grammar hack, the one that allows multi-line lambdas, would
> not have the problem that it does if the colon-ized versions of
> compound statements were limited to having only a single statement and
> would thus be a much more practical solution.
What percentage of users need multiline lambdas? If a lambda needs
more than one line, isn't it a good candidate for being a named
function? How many of these lambdas will exist in a typical
application? Crippling the whole language to facilitate a
occasionally used feature doesn't seem to be a good tradeoff.
> The real point to this proposal was to get people talking in a more
> productive direction. We now have a straw man implementation that can
> be toyed with until a suitable solution is found. I did not actually
> expect this proposal to be accepted without change. So, if anyone
> would like to make suggestions for a change to the proposal, please do
> so. If I like the change I'll even implement it and post a new patch :)
Proposing a solution generally indicates a problem exists that must be
solved. The most productive direction this conversation could take
would be to drop it. That would give Guido more time to work on
other pressing matters. Consider this fundamental law of maximizing
productivity:
If it ain't broke, don't fix it.
Tinkering with a working system is generally a bad idea. The
proponents of changing the grammar have still failed to explain why
the new syntax is essential.
I would like to offer my own solution to the current grammar change
debate. I propose the issue of changing the grammar be dropped for six
months. If at that time, a need for changing the syntax is identified,
and a working implementation, can be demonstrated, this debate can be
reopened.
Michael