English-like Python

[Aaron Brady]

On Jan 20, 12:58 pm, Joe Strout <j... at strout.net> 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.
>
> Your "f" example above works fine in RB too, though with such an
> abstract example it's a little hard to see why it's so cool.
>
> Eliminating unnecessary parentheses does a lot to improve the
> readability of the code IMHO.
>
> Cheers,
> - Joe

Unambiguity and readability are two different things.  (This should be
a quasi-tangent, neither agreed, nor opposed, nor unrelated to what
you said.)

If you have

f "abc" 123

it's unambiguous, but, if you have

g f "abc" 123 "def"

there's no sure way to determine where the call to 'f' stopped, and
the one to 'g' resumed (or, as in Python, if 'f' was even to be called
at all, as opposed to 4 parameters to 'g').

If you allow commas, you can make some progress, though I don't have a
rigorous formula.  But, for example,

g f "abc", 123 "def"

can only mean:

g( f( "abc", 123 ), "def" )

But something tells me it doesn't extend, especially since commas are
used elsewhere than function calls.  And certainly, it's not readable
at a glance.

English has that problem and kind of glaringly, by the way.  You don't
always know how the speaker's subordinate clauses are nesting.  Not
just with clauses, but modifiers, as in "The Purple People Eater".  So
I don't know how you expect to design a programming language after it.