Python's Lisp heritage

[Alex Martelli]

Ben Wolfson wrote:
        ...
>> Anyone for Haskell's f a b c ...?  Now THAT is clean and elegant... the
        ...
> No parentheses in the simple case, maybe, but at least in SML, which is
> similar, the parentheses can multiply pretty quickly if one of the
> parameters is the result of a function, or a function returns a function:
> (f a (g b)) (h c) isn't all that pretty, unless you like Lisp.  Haskell
> may be smarter about that kind of thing, though.

No, you do need SOME parentheses, if the normal priority is not the 
one you want -- I'd *hate* a language so "smart" as to parse
        f a g b h c
in many different ways depending on declared or inferred types for
the identifiers, or anything like that (usability == 0).

Still, I don't see much in it either way between the parenthesization
you deem "not all that pretty":
        (f a (g b))(h c)
and the Python equivalent:
        f(a, g(b))(h(c))

The former may be obviously reduced to:
        f a (g b) (h c)
"a function returning a function" is the USUAL case after all, for all
situations that in other languages you'd consider "a function with N>1
arguments".  So, you don't need the parentheses around
        f a (g b)
although you may of course use redundant parentheses if and when
you feel they make an expression prettier, as in any other language:-).

The parentheses around (g b) ARE needed because you want to
indicate that g applies to b and the RESULT of that is an argument
to the unnamed function returned by (f a) -- otherwise, g would be
the argument to (f a), and b the argument to the resulting unnamed
function f a g , aka ( (f a) g ) if you want redundant parentheses.


Alex