g> As was said before (I forget by whom) I don't like such important
g> matters as whether 'end' is required to be decided by the presence or
g> absence of a tiny colon.
And... as I said before (I forget when), it is all a matter of
perspective. Assume for a moment that the Python grammar is as I
proposed, but that the colon-ized versions of the compound statements
had yet to be conceived. Would you then be opposed to adding the
colon as a way to indicate that only a single statement, with no
terminating 'end' would follow. Now, I realize that my patch does
allow more than a single statement, but that was done only for back
compatibility.
I would not, however, be opposed to replacing the colon with a new
keyword, 'do' for instance, that would indicate an end statement was
to close the block. I choose not to do this for two reasons: first,
it would mean the addition of three new keywords, 'end', 'do', and
'is'. After all, 'def x(a) is...' makes much more sense than 'def
x(a) do...'. And second, I like the minimalist nature of the change
as it was proposed.
g> Don's grammar also allows atrocities like
g> if t:
g> st
g> else
g> st
g> end
g> and
g> if t
g> st
g> else:
g> st
g> # no end here!
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.
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.
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.
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 :)
--Don
______ ______
\_\_\_\ /#/#/#/
\_\_\_\ ______
\_\_\_V#/#/#/ Donald Beaudry don@vicorp.com
\_\_/#/#/#/ V. I. Corporation uunet!vicorp!don
\_/#/#/#/ 47 Pleasant Street PHONE: (413) 586-4144
V#/#/#/ Northampton, MA 01060 FAX: (413) 586-3805