Re: Pythonic indentation (or: beating a dead horse)

After listening to this debate for some time, the position of allowing  
optional Pythonic indentation seems increasingly persuasive.

First, no one is proposing to eliminate "end".  The "end" keyword can  
still be used just as it always was. If we adopt J. Haas' proposal  
that indentation blocks be demarcated by a colon, as in:

     if x:
         foo

...then the preprocessor can run ALL existing Ruby code unchanged,  
even if the "end" keywords are misaligned.  Further, the colon gives a  
visual cue that indentation syntax is being employed.  We could  
further reduce some of the ambiguity from which Python suffers by, for  
example, disallowing tabs as marks of indentation.  Spaces only, please.

Second, the idea that this change would be hard to implement has been  
mostly rebutted, in my opinion.  Caleb's code does the job.  Ruby  
could be trivially transformed to (a) include the preprocessor, and  
(b) run it on Ruby files before processing them -- i.e. before lexing,  
parsing, etc.  That would be the dead-easy way to implement this  
proposal, requiring very little C.

Third, there is no doubt about the objective fact that Ruby code that  
removes optional "end" keywords will be shorter, and I think  
practically everyone agrees in principle with the idea that terseness  
is a virtue unless there is some specific reason for being redundant.

Fourth, I thought the point was quite persuasive that Ruby also allows  
semicolons to be entirely optional except in those specific cases on  
the same line where they are needed.  This behavior and philosophy is  
exactly analogous to the current proposal.  You could put a semicolon  
at the end of every line in Ruby right now, but no one does.  Why  
not?  Because they are redundant, because they are visual noise.

The point that has not been so thoroughly deconstructed are all the  
possible odd syntactical limitations that might exist if this proposal  
were adopted.  For example, I saw someone saying that "end" would not  
be allowed inside any block that used indentation.  If this were  
really necessary, to me, it would be a point against the significant- 
whitespace proposal.  I don't really see why it would be necessary.  I  
do see that, for the code to work with Caleb's preprocessor, any "end"  
keywords used inside an indented block would themselves need to be  
indented properly.  But this is another example of a minor syntactical  
"gotcha" that could or would pop up.  How many other such kinks or  
gotchas do you suppose there might be, once we delve more deeply into  
actual implementation?

Having said that, I think the main problem boils down to aesthetics.   
Some people, myself included, would prefer the whitespace-aware option  
rather than typing a string of "end" keywords assuming they are  
unnecessary.  Others find the "end" keywords to be visually helpful.   
To argue against optional removal of "end" is to argue that others  
should not be given the choice of removing "end" in their own code.   
This position -- denying to others the option of doing things in a way  
they prefer -- seems like a hard position to argue for.  However, I  
think from the viewpoint of people who do not like significant  
whitespace, the problem is that they know that if the proposal were  
adopted, sooner or later they will encounter code that is formatted in  
this way, and they will then be "forced" to deal with code they find  
unpleasant.  In other words, someone will be forced to deal with code  
they find difficult to work with, and those who prefer "end," quite  
naturally, do not want to have to be the ones to deal with this.

I think in reality, the imposition on those who prefer "end" will be  
minor.  All their own code will have "end".  The issue will arise in  
situations where for some reason a person who prefers "end" is forced  
to maintain code that uses indentation.  This could be exacerbated by,  
e.g., a corporate coding standard that requires indentation syntax  
wherever possible.  This, I think, is the future that those who like  
the "end" keyword are trying to avoid.  If the significance of  
whitespace were guaranteed never to be an issue that confronts them,  
then I think few people would object to the inclusion of optional  
indent-aware syntax.

I don't have an answer to this aesthetic problem, and I don't think  
one is possible, since taste is taste and one cannot be argued out of  
their preferences.  However, i would say that allowing people to do  
things in different ways is part of the spirit and philosophy of  
Ruby.  It's not that Ruby seeks to be able to do things in many ways,  
but Ruby does make it easy to do things in different ways if those  
ways are convenient and desirable to a substantial number of people --  
e.g., curly brackets versus do..end, aliases, << versus insert, etc.   
Also, making redundant syntax optional, e.g. semicolon, is, IMO,  
entirely within the spirit and philosophy of Ruby.  It's hard to  
understand why Ruby would allow semicolons to be optional but not  
"end" keywords.

steven