castironpi at gmail.com
Wed Jan 21 09:57:49 CET 2009
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:
> 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
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-
More information about the Python-list