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 selfdelimiting, 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 x1 x+1
Oh, and it *also* accepted explicit commas, too, so all of these were
legal as well: ;} ;}
f x  1, x + 1
f x1, x+1
f, x  1, x + 1
f, x1, x+1
+
 > I have programmed with Lisplike 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 x1 x+1]*z" (which, given
operator precedence, parsed to "(+ (* (f ( x 1) (+ x 1)) z) y)".
Rob
[1] The parser was actually recursivedescent for control structures
and simpleoperatorprecedence 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)5722607