My solution calls the first parameter as a function when the object in the functional position is a number or symbol. The math operators are then overridden in infix.arc to do infix evaluation when they get a function in their parameter list.
This eliminates the need for explicit infix and prefix macros (the sqrt call below uses prefix notation in the middle of the infix expression):
(3 + 4 * 5 - (sqrt 36))
If we had first class macros we might even be able to convert the expression at compile time rather than run time.
I definitely think there is a lot to improve on, and your version of the infix macro has some features mine doesn't (e.g. associativity).
I don't know if my version would work for comparison logic... The program actually switches when the functional position is a number or symbol, and since t and nil are symbols, it would theoretically work.... But point is, my current version is not very extensible.
I'd seen your post so I was hesitant to post mine, but I think it's worth it because we're using two different approaches.
I'm trying to let the user specify what is/isn't infix, which is why I detect operators rather than numbers. I want the macro to have uses beyond infix arithmetic e.g. parsers expressed in BNF.
Also, mine is written entirely in Arc, so it's a good demonstration of what Arc can do, not to mention good practice for me.
I fully support what you are doing, people might not want implicit infix math all the time. It also looks like you are thinking more toward how to let the user define infix operators, which my version doesn't do a good job with.
I actually rewrote my version in arc, except for 2 lines in ac.scm (one which implemented something pg was already thinking about, and one which allowed (eval (list + 3 4))). I posted a comment about it on my original post, but I think it got buried so far down that no one ever saw it.
