Tim said:
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
