On May 28, 2009, at 12:39 PM, Caleb Clausen wrote:

> On 5/28/09, Eleanor McHugh <eleanor / games-with-brains.com> wrote:
>> Some cases have been presented elsewhere in this thread where the
>> pythonic indentation would fall flat: specifically for expressions of
>> the form
>>
>> a = case x
>>   when...
>>   when...
>>   when...
>> end if y
>
> I feel that I did address this point adequately already, so it's
> annoying to see both you and Joshua Ballanco bring it up again,
> without even acknowledging that I had done so. Perhaps you don't agree
> with my points, but as you haven't tried to rebut them, I think it
> more likely that you did not read what I had to say at all.
>
> To reiterate: Yes, you can't really write that expression without an
> end. Cases like this are why I decided, in my preprocessor, to allow
> users to put in an end if they really want to. It's sufficiently rare
> to need more tokens on the same line after an end that it's not
> unreasonable to ask the user to type an extra (normally unnecessary)
> end in those cases. 99% of ends can still be eliminated. If that
> proportion were lower -- 50% or 75% or even 90%, I would say that the
> convenience of not having to type end is outweighed by the additional
> burden of remembering that at least a tenth of the time you do anyway.
> But when you get it down to the less than once a week level, a small
> exception like this is ok. Very occasionally, you have to type end in
> endless ruby. Very occasionally, you have to type pass in python. BFD.

Exactly,  this is a bit of a straw man issue.  Nobody is saying get  
rid of all
ends.  Use end where it makes sense,  but if it's just wasting space  
there is
no need.

>
>
>> It's not a common formulation in this form, but it highlights the
>> problem of using significant whitespace as an expression delimiter in
>> expression-based languages. Were there a way to solve this ambiguity
>> elegantly then there would be a case in favour of introducing  
>> pythonic
>> indentation, but until then this would either introduce an  
>> unnecessary
>> limitation on the things that can be expressed in ruby or lead to a
>> considerably more complicated lexer that might have other  
>> implications.
>
> I disagree that indentation sensitivity 'considerably' complicates the
> lexer. endless.rb has about 180 lines of code, of which at least 25%
> are concerned with the mechanics of pre-processing and wouldn't be
> necessary if it were fully integrated into the lexer. It was
> moderately difficult, but not bad. Quite a few other ruby features
> (here documents, utf-8 in identifiers, the ambiguity of some
> operators) were what I would call complicated; by comparison
> indentation was pretty easy.

That code was pretty standard looking.   It had some functions in a  
class.  The
nesting wasn't particularly deep.  Are classes with functions now  
considered
code smell?  Also, if I recall correctly the Ruby core libraries are  
about 16%
end.   That ought to be, relatively speaking, pretty good Ruby.   So
ironically, if Ruby added this capability it's own code base would  
shrink.

>
>
>> The real answer to this issue is to have a pythonic indentation
>> pre-processor for those who find that of use, and to leave the
>> core language syntax alone.
>
> I did, already.
>

I think I'll use it.  That said, the case for giving core Ruby this  
capability
seems to be getting stronger.