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.

> 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.

> 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.