Python's Lisp heritage

[Alex Martelli]

Jacek Generowicz wrote:
        ...
> The purpose of the parentheses (in this context) is to call functions
> and associate parameters with those function calls. Python has a not
> too dissimilar use of parentheses:

Anyone for Haskell's f a b c ...?  Now THAT is clean and elegant... the
concept of "a function with > 1 parameter" is unnecessary (as Haskell
Curry pointed out), so there's no need to associate a function with any
more than its first (and only) parameter: f a returns an unnamed
function which takes argument b, returning another unnamed function
which takes argument c.  Look, ma, no parentheses -- and no tricks
needed to achieve that, just some deep mathematical reality:-).

>   that you would really like to extend the set of infix operators,
>   with say @, to allow you to call splark without having to type those
>   infernal parentheses. Is it going to be easier in Python or in Lisp?

Haskell -- it has definition of new infix operators as a built-in.  But
THAT, IMHO, is a design error: languages with mutable syntax are
spending far too much complexity on syntax sugar -- and not to
good overall effect either.  The language's "new improved" syntax
may LOOK spiffier when you first see a new op introduced in some
article or tutorial about the language -- but when the rubber hits
the road, some poor devil of a programmer is going to have a very
hard time decrypting expressions using the new op -- where does
he or she go look up precedence and associativity, and how much
work does it take to parse them mentally...?

Prefix (and postfix) only need define arity (and Curry's result makes
that a don't-care for prefix:-), infix needs precedence and
associativity, and THAT is hard going.  I don't even _remember_
how a `f` b `g` c parses in Haskell (where stropping `f` is one simple
way to use a function f)... (f a) (b `g` c), or (f a b) `g` c ...?


Alex