On 28 May 2009, at 17:39, 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. Possibly not. This has been a long thread and I'm sure I've either missed posts or misunderstood their intent. > 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. And as I've said elsewhere, how you handle things in a preprocessor is entirely up to you. I'm not your target audience as I don't like pythonic indentation - it's one of the reasons I didn't take to the language despite several attempts to get into it - but I'm sure those who are won't mind writing the occasional end statement. >> 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. Until I have time to study your code I'll take your word for that. Have you tried framing endless.rb as a patch for MRI's lexer? and if so how significant are the changes? >> 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. Then put out an [ANN] and if the community finds pythonic indentation valuable, it'll catch on. Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net ---- raise ArgumentError unless @reality.responds_to? :reason