English-like Python

[Aaron Brady]

On Jan 21, 2:36 am, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> wrote:
> On Tue, 20 Jan 2009 11:58:46 -0700, Joe Strout wrote:
> > Aaron Brady wrote:
>
> >> I think it would be a good step if you could make some sensible
> >> interpretation of a typical statement without its parentheses.
>
> >> f "abc" 123
> >> -->
> >> f( "abc", 123 )
>
> >> It would be just the thing in a couple of situations...
>
> > Such a language is possible -- take a look at REALbasic sometime.  RB
> > certainly has its problems (mainly bugs), but the language syntax is
> > beautiful.  To your point, parentheses are not required around any
> > method call that (1) has no return value, or (2) requires no parameters.
> >   Example:
>
> >   LogError "Walk has gotten too silly", CurrentTime
>
> > Here, LogError is a method call that takes two arguments, and
> > CurrentTime is a method call that takes none.
>
> That seems ambiguous to me. As a non-RealBasic programmer, I can see at
> least four meanings it could have. Translated into Python, they are:
>
> LogError("Walk has gotten too silly", CurrentTime)
> LogError("Walk has gotten too silly"), CurrentTime
> LogError("Walk has gotten too silly", CurrentTime())
> LogError("Walk has gotten too silly"), CurrentTime()
>
> Of course this assumes that RealBasic has an equivalent of tuples, and
> treats functions as first class objects.
>
> But even if RB doesn't have these things, I question that the syntax is
> "beautiful". Consider some arbitrary method Foo. If you see this:
>
>     Foo
>
> Is that legal RB syntax? Maybe yes, maybe no. It all depends on what Foo
> does. If it returns no result, then it's legal. If it returns a result,
> it isn't. So the question of whether syntax is legal depends, not on the
> syntactic elements involved, but on the *semantics* of the method
> (whether or not it returns a result).

If you could deduce the semantics of a function from the syntax
always, you could follow Erik's observation about Logo.  Then
expressions would have unique interpretations, except where a function
takes no arguments and functions are first class objects.  In other
words,

g f "abc" 123

would have an exact meaning, since f would just get the innermost n
arguments, that since 'n' would be a known quantity.  (Order of
precedence would handle 'g f "abc" + "123"'.)

> > Eliminating unnecessary parentheses does a lot to improve the
> > readability of the code IMHO.
>
> But they're not unnecessary, at least not in Python, they're useful for
> distinguishing between calling the function and the function itself.

Natural language doesn't have the equivalent of parentheses, which
goes back to Steven's point about a beautiful math structure vs. a
beautiful NL sentence.  Did anyone have to diagram sentences in
grammar school?  It's not like the essentials for communication
involve deeply nested sentences; you can get by with a few simple
declarations, so you and your company will reject anything "higher-
order".