Python from Wise Guy's Viewpoint

[Matthew Danish]

On Mon, Oct 20, 2003 at 01:52:14PM -0700, 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]
> #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).

And lambda notation is: \xy.yx or something like that.  Math notation is
rather ad-hoc, designed for shorthand scribbling on paper, and in
general a bad idea to imitate for programming languages which are
written on the computer in an ASCII editor (which is one thing which
bothers me about ML and Haskell).

> - "f x y" is unique to the Haskell and LISP families of languages, and
> implies that most library functions are curried.  Otherwise you have a
> weird asymmetry between curried calls "f x y" and uncurried calls
> which translate back to "f(x,y)".  

Here's an "aha" moment for you:

In Haskell and ML, the two biggest languages with built-in syntactic
support for currying, there is also a datatype called a tuple (which is
a record with positional fields).  All functions, in fact, only take a
single argument.  The trick is that the syntax for tuples and the syntax
for currying combine to form the syntax for function calling:

f (x, y, z)  ==>  calling f with a tuple (x, y, z)
f x (y, z) ==> calling f with x, and then calling the result with (y, z).

This, I think, is a win for a functional language.  However, in a
not-so-functionally-oriented language such as Lisp, this gets in the way
of flexible parameter-list parsing, and doesn't provide that much value.
In Lisp, a form's meaning is determined by its first element, hence (f x
y) has a meaning determined by F (whether it is a macro, or functionally
bound), and Lisp permits such things as "optional", "keyword" (a.k.a. by
name) arguments, and ways to obtain the arguments as a list.

"f x y", to Lisp, is just three separate forms (all symbols).

> 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.

Nah, it should still be able to report the line number correctly.
Though I freely admit that the error messages spat out of compilers like
SML/NJ are not so wonderful.

> I think #9 is inconsistent with #1.

I think that if the parser recognizes that it is directly within a [ ]
form, it can figure out that these are not function calls but rather
elements, though it would require that function calls be wrapped in (
)'s now.  And the grammar would be made much more complicated I think.

Personally, I prefer (list a (b c d) e f).

> 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).

Hmm, rather curious paper.  I never really though of "f x" using
whitespace as an operator--it's a delimiter in the strict sense.  The
grammar of ML and Haskell define that consecutive expressions form a
function application.  Lisp certainly uses whitespace as a simple
delimiter.  I'm not a big fan of required commas because it gets
annoying when you are editting large tables or function calls with many
parameters.  The behavior of Emacs's C-M-t or M-t is not terribly good
with extraneous characters like those, though it does try.

-- 
; Matthew Danish <mdanish at andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."