On May 20, 12:25 ¨Βν¬ Τοξω ΑςγιεςΌτ®®®ΐνεδιοθ®γονχςοτεΊ > I already responded to this. ¨Β ηυεσωοδιδξ§τ σειτ I responded to your response, I guess you didn't see _that_. Tell me what's wrong with the following alternatives to your examples: > if foo > blah > elsif bar > blah2 > else > baz Just like with your case example before, whoops! You're missing an end, and the parser will complain when it sees the end-of-file without a missing end. And just as I said with your case example before, I sure hope this missing end isn't in the middle of a long file or you get to spend a lot of time scrolling through your code looking for the place where it's missing. But if we amend your example to if foo blah elsif bar blah2 else bar end ...I really don't see what's wrong with this as an alternative: if foo: blah elsif bar: blah else: bar No end necessary. > Begin statements (ala try/catch in Python) > > begin > somecode > morecode > rescue FooError > some_rescue_action > rescue BarError > another_rescue_action > ensure > something_gets_done Again, you're missing an end. Applying the same pattern I applied in the if and case examples, I do not see what the problem is. How is it any less functional than the current Ruby? > Each of these statements is an expression with multiple clauses. ¨Βοχ δο ωο> tell when these expressions are complete? ¨Ββφιουσμω ξαιφΆδεδεξεξ> of expression" approach doesn't work in these cases. Okay, I think I see what you're saying now. But each of those also, in the clauses after the first one, begins with a keyword that is not valid except as part of the previous expression. Does it solve the problem if dedenting ends an expression unless it's immediately followed by a keyword that makes no sense except as a continuation of the expression? > This doesn't work in a language where everything is an > expression, because all expressions must be treated the same and all > expressions must have an expression terminator (newline or semicolon) You keep on saying this, yet I have not seen one example of code that demonstrates that using dedent couldn't work. Basically, we're looking for some code which, if you removed the all ends, a script following simple deterministic rules would not be able to unambigiously decide where to put them back. I agree that "put an end wherever you see a dedent" is naive and wouldn't work... but "put an end wherever you see a dedent which isn't followed by a keyword which extends the current expression, such as elsif or rescue or ensure" might.