Eleanor McHugh <eleanor / games-with-brains.com> writes:

> On 28 May 2009, at 15:06, Juan Zanos wrote:
>> As I've watched this debate unfold I've watched the stronger  
>> criticisms fall
>> apart.  The strongest type of criticism would be that it can't be  
>> done, or that
>> it's too hard to be done.  But the impossible examples seem to be  
>> defeated
>> fairly easily.   Moreover, the solutions are backward compatible to  
>> existing
>> Ruby.
>
> 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
>
> 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.

There's a simply way to solve it.  Since everything is an expression,
we can easily wrap expressions and subexpressions in parentheses, and
by the way resolve any ambiguity:

(a = ((case x
       when ...
       when ...
       when ...
       end) if y))

((a = (case x
       when ...
       when ...
       when ...
       end))
 if y)



> Begin..end indicates explicitly that a series of expressions is  
> contained between these statements and that their return value is  
> available to use as part of a more complex expression which may have  
> modifiers, something of great value to some of us. Your experience  
> might well be very different and this might not be a use case you  
> commonly encounter, but please don't make the mistake of believing  
> that your use case invalidates the utility of this language feature.  
> Most of the code I work on takes this form and has perhaps a 10%  
> density of 'end' statements, if that.

It could be reduced to 0%, if you notice that the close parenthesis is
all that is needed to end the subexpressions.

(a = ((case x
       when ...
       when ...
       when ...) if y))

((a = (case x
       when ...
       when ...
       when ...))
 if y)


Also we could decide to always put the operator first, to simplify a little:


(a = (if y
         (case x
           when ...
           when ...
           when ...)))

(if y
    (a = (case x
           when ...
           when ...
           when ...)))

so it would be clearer what is IF'ed.


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

Exactly.  The concrete syntax should be purely a question of
presentation and user interface, that should be dealt with by the
editor.  Source files could be kept in s-exp form, like it was
intended originally (50 years ago).

-- 
__Pascal Bourguignon__