I said you can make a mechanism to define new infix operators, but it's not very good. Then you quoted so as to imply I didn't know that, and said that actually some languages have it.
infix only works with a limited number of built in
things, it doesn't scale nicely. i suppose you could
change this, e.g. make # a special character, and then
you can define infix foo then write arg1#foo#arg2. but
like, that's ridiculous. no one wants to do that with
functions in general.
First, there are languages which have infix functions as a first class concept in the language (e.g., J, and I would suppose APL and K), so it isn't that infix doesn't scale. Secondly, even in languages which have the call() convention, user-definable operators can coexist (see logix, for example, which is an infix macro system built on top of python).
Additionally, you don't have to have an arg1#foo#arg2, as long as you're willing to use spaces to separate things, the way that lisps, forths, and so on do.
? well, right or wrong, you are definitely deviating from the mainstream. that is, C and java coders will agree with me that prefix, and unlimited arguments, is better. the only difference they'll do in the general case of function calls is to add commas in the argument lists, and move the open-paren to the right one token.
i think not using infix function calls has nothing to do with why people are put off by s-expressions.
No. Nowhere am I advocating that. Rather, I'm pointing out that it's not an obviously ridiculous idea -- people have implemented it, and some people like it.
"i think not using infix function calls has nothing to do with why people are put off by s-expressions."
but how can it be a reason people dislike lisp when C and Java programmers put their function calls in prefix order, too? the vast majority of programmers do function calls that way, and prefer it.
and infix function calls in general is obviously a bit ridiculous because it doesn't scale. why would you want all functions to take 2 arguments? or were you going to
(a b foo x y z)
for a function of 5 arguments? and memorize which side to put the extra one on, and what order they go in, etc?
Curi, I'm not saying it's a good reason to dislike lisp. If I thought it was a good reason, I wouldn't like lisp, and yet lispy languages are my favorites (most of my lisp code has been CL, but Arc is interesting at 0.0).
There are a number of possible solutions to your question about infix functions. In J, insofar as I understand it, all functions take either one or two arguments, but the arguments can be arrays, so you often get the effect of more than two arguments.
For example (it's been a while) the form * / 2 3 4 would have the function *, the function /, and an array or list of three integers. J is parsed right to left, so the array is collected first, and then there's a modifier function '/' which takes two arguments: a function on the left, and an array on the right, and applies the function to each of the elements of the array (like map in lisps), outputing the new array. I don't know the details anymore of which symbols are what primitives, but J is interesting, in my opinion.
Alternatively, for your example, you might do
(a b) foo (x y z) ; or
(a b, foo, x y z) ; or
a b Foo x y z ; if functions have their own
naming rules like in Erlang, or
a b foo! x y z; # where the bang means call, or
something else. Surely you can come up with 10 or 12 yourself. Some of these scale in some ways, and not in others; you could have a rule that you can only have one call per line, to remove ambiguity. That sounds rather restrictive, but so do Python's indentation rules when you first hear of them, and that works out okay, in my experience. I don't think any of them lend themselves to nice general-purpose macros, but I might be wrong.
