However...
As was said before (I forget by whom) I don't like such important
matters as whether 'end' is required to be decided by the presence or
absence of a tiny colon.
Don's grammar also allows atrocities like
if t:
st
else
st
end
and
if t
st
else:
st
# no end here!
Fixing this latter anomaly would require an even larger barrage of
rather similar grammar rules and corresponding code in compile.c.
Contrast this to my "optional end clause" solution, which would
require minimal changes, and has additional redundancy (a la Ada) as
well ("end if", "end for", etc.).
Don claims that an optional end clause is no more useful than an
optional "# end" comment. This may be true, but does his solution
have any more value? I doubt it. If the user provides correct
indentation, a missing (or unexpected) end clause is immediately
noted by the discrepancy in indentation. If the user cannot promise
correct indentation, the only solution is to require end clauses
everywhere in the file (as does my "pindent -r" script).
I'd like to hear what people think about this matter (except Tim P and
Steve M -- you are already in the top three :-).
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.
As I said previously, why stop at a multi-line lambda? A more
"orthogonal" solution would be multi-line "valof" blocks as in BCPL!
Anyway, I don't see how this would work -- hints, please?
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>