Adding print-style function calls, and preproc plugins

[Tim Hammerquist]

Me parece que Gerson Kurz <gerson.kurz at t-online.de> dijo:
> 1) normally, you call functions in python like this:
> 
> name '(' arg { ',' arg } ')'
> 
> however, 'print' is a special function in that its arguments can be
> written without enclosing brackets. Wouldn't it be nice if you *could*
> call your "normal" functions in the same way? Would that require too
> much of a change to the python language?

It diverges too far from what I would like Python to be. (Are you
reading, Guido?)  I can take advantage of what you describe in Perl, but
Python's precision is part of the romance. <g>

> There might be a slight ambiguity when function names are used without
> arguments, because it then could be interpreted as either the function
> object or the function call; but then again, I see writing the
> function name as object without assigning it to some variable or some
> such as rather pointless. 

There would be ambiguity, which would require a lot more work on the
compiler's part, and a lot more thought on the programmer's part to
remember all the rules.  I've wanted to write Python funcs that work
like statements (as you describe), but I soon saw that leads down the
slippery slope toward _other_ languages.  Adding parens is a small price
to pay, IMO.

> IIRC VB (yuk!) can do something similar. But then, VB is possibly the
> *worst* kind of advocacy possible.

Yes. VB functions (that return a value) _do_ require parens around the
arguments. VB subs (that *don't* return a value) do _not_ require parens.
OTOH, in this case, the parse just assumes everything from the sub name
to EOL are arguments. Very little ambiguity.

HTH

-- 
You're quite free to convert your strings to byte arrays and do the
entire pattern tree by hand in pure logic code if you'd like. By the
time you finish most of the rest of us will be doing contract work on
Mars.
    -- Zenin, comp.lang.perl.misc