Adding print-style function calls, and preproc plugins

[Steven D. Majewski]

On Thu, 30 Aug 2001, Gerson Kurz wrote:

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


A *SLIGHT* ambiguity ! 

It's extremely ambiguous. 

What does:
	"e1 e2 e3 e4 e5" 
mean when more than one of those e's is a function ? 
Can you tell which ones represent function calls if you don't
know the value of all of the e's ? 


Does function call bind more or less tighly than other operators like  "+" ? 
i.e. does:
	  f1 a + b 
mean f1( a+b) or f1(a) + b ?

And, since in Python, any variable name can be bound to a function,
and all names are dynamic, can you come up with an operator precedence 
that isn't context dependent ? i.e. does the binding and order of
evaluation of "e1 e2 e3 e4 e5" change depending on the value of the e's ? 


One of my complaints against Lisp syntax was that it didn't make 
different things -- function calls and control syntax of FEXPR's 
look different, so the general structure and flow of a program 
text wasn't obvious if you didn't know what all the words meant. 
But at least Lisp keeps the parenthesis to maintain some structure.

Forth, like a reverse Polish calculator, doesn't need parends around
function args, but that's because almost every token is a verb that
does something right away -- the exception being that some verbs 
"eat up" other tokens up to some delimiter and use them as names or
strings. 

Haskell manages to skip the parends by making function call bind
very tightly -- and since it's a highly functional language, it
can consider functions of multiple args as a series of curried
functions of a single arg, so there's no ambiguity. 

I can't think of a way to make it work in Python! 

-- Steve Majewski