Marcin 'Qrczak' Kowalczyk  <qrczak@knm.org.pl> wrote:
+---------------
| "Kaz Kylheku" <kkylheku@gmail.com> writes:
| > The commas don't serve any purpose, other than to add clutter.
| > So a better notation than f(x, y, z) is quite simply f(x y z).
| 
| The commas do serve a purpose: they avoid extra parens if arguments
| are not self-delimiting, as in f(x - 1, x + 1).
+---------------

Actually, if the grammar permits, one can use a simple operator 
precedence parser[1], and then violations of the "must have at least
one operator between every pair of values" rule can be taken as
being an implicit comma. The "P'Lite Scheme" infix parser I did
back in 1996 did this. It would parse this:

    f x - 1 x + 1

into this:

    (f (- x 1) (+ x 1))

Yes, it was a horrible hack, and did have the possibility of masking
some real user errors, but it made the syntax look more like what Tcl
[my main "competition"] accepted, especially if you left the optional
spaces out in each infix expression:

    f x-1 x+1

Oh, and it *also* accepted explicit commas, too, so all of these were
legal as well:       ;-}  ;-}

    f x - 1, x + 1
    f x-1, x+1
    f, x - 1, x + 1
    f, x-1, x+1

+---------------
| > I have programmed with Lisp-like semantics using the f(x,y,z) syntax.
| > It's ugly. The comas really are a problem.
| 
| Indeed they are quite ugly if the f(x,y,z) syntax is used for all
| syntactic constructs.
+---------------

I agree. P'Lite *didn't* support "f(x,y,z)"!! It used the Tcl "[...]"
for function call subexpressions, e.g., "y+[f x-1 x+1]*z" (which, given
operator precedence, parsed to "(+ (* (f (- x 1) (+ x 1)) z) y)".


-Rob

[1] The parser was actually recursive-descent for control structures
    and simple-operator-precedence for expressions, like BLISS used.
    For a language like P'Lite, this is easily accomplished simply by
    giving the control/special forms very high operator precedences...

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607