Python's Lisp heritage
Alex Martelli
aleax at aleax.it
Sat Apr 27 18:34:20 EDT 2002
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
More information about the Python-list
mailing list