Python from Wise Guy's Viewpoint

[Joachim Durchholz]

Tim Sweeney wrote:
>>
>>1. f(x,y,z) sucks. f x y z  would be much easier to type (see Haskell)
>>   90% of the code is function applictions. Why not make it convenient?
>>
>>9. Syntax for arrays is also bad [a (b c d) e f] would be better
>>   than [a, b(c,d), e, f]
> 
> Agreed with your analysis, except for these two items.
> 
> #1 is a matter of opinion, but in general:
> 
> - f(x,y) is the standard set by mathematical notation and all the
> mainstream programming language families, and is library neutral:
> calling a curried function is f(x)(y), while calling an uncurried
> function is f(x,y).

Well, in most languages, curried functions are the standard.
This has some syntactic advantages, in areas that go beyond mathematical 
tradition. (Since each branch of mathematics has its own traditions, 
it's probably possible to find a branch where the functional programming 
way of writing functions is indeed tradition *g*)

> - "f x y" is unique to the Haskell and LISP families of languages, and
> implies that most library functions are curried.

No, Lisp languages require parentheses around the call, i.e.
   (f x y)
Lisp does share the trait that it doesn't need commas.

 > Otherwise you have a
> weird asymmetry between curried calls "f x y" and uncurried calls
> which translate back to "f(x,y)".

It's not an asymmetry. "f x y" is a function of two parameters.
"f (x, y)" is a function of a single parameter, which is an ordered pair.
In most cases such a difference is irrelevant, but there are cases where 
it isn't.

 > Widespread use of currying can lead
> to weird error messages when calling functions of many parameters: a
> missing third parameter in a call like f(x,y) is easy to report, while
> with curried notation, "f x y" is still valid, yet results in a type
> other than what you were expecting, moving the error up the AST to a
> less useful obvious.

That's right.
On the other hand, it makes it easy to write code that just fills the 
first parameter of a function, and returns the result. Such code is so 
commonplace that having weird error messages is considered a small price 
to pay.
Actually, writing functional code is more about sticking together 
functions than actually calling them. With such use, having to write 
code like
   f (x, ...)
instead of
   f x
will gain in precision, but it will clutter up the code so much that I'd 
exptect the gain in readability to be little, nonexistent or even negative.
It might be interesting to transform real-life code to a more standard 
syntax and see whether my expectation indeed holds.

> In general, I'm wary of notations like "f x" that use whitespace as an
> operator (see http://www.research.att.com/~bs/whitespace98.pdf).

That was an April Fool's joke. A particularly clever one: the paper 
starts by laying a marginally reasonable groundwork, only to advance 
into realms of absurdity later on.
It would be unreasonable to make whitespace an operator in C++. This 
doesn't mean that a language with a syntax designed for whitespace 
cannot be reasonable, and in fact some languages do that, with good 
effect. Reading Haskell code is like a fresh breeze, since you don't 
have to mentally filter out all that syntactic noise.
The downside is that it's easy to get some detail wrong. One example is 
a decision (was that Python?) to equate a tab with eight blanks, which 
tends to mess up syntactic structure when editing the code with 
over-eager editors. There are some other lessons to learn - but then, 
whitespace-as-syntactic-element is a relatively new concept, and people 
are still playing with it and trying out alternatives. The idea in 
itself is useful, its incarnations aren't perfect (yet).

Regards,
Jo