|Wart now supports a quick-n-dirty implementation of an infix scheme. Here's an excerpt from http://github.com/akkartik/wart#readme with the details:|
You don't need spaces around infix ops.
wart> (3 + 1)
Infix ops don't compromise homoiconicity; wart parses them into lisp forms so your macros don't have to worry about them:
Infix ops are always left-associative.
=> (+ a b)
Range comparisons are convenient as long as they return the last arg on success (because of left-associativity) and pass nils through:
=> (+ (+ a b) c)
You can mix infix ops with regular prefix lisp:
(a > b > c)
=> (> (> a b) c) ; watch out if b is nil!
(> nil x) ; should always return nil!
Operator precedence is not hardcoded. Instead, there is just one rule: operators surrounded by whitespace have lower precedence than operators that are not.
(a + (f b))
=> (+ a (f b))
(a + f.b)
=> (+ a (f b))
=> (fib (- n 1))
(f a + b c*d)
=> (f (+ a b) (* c d))
You can create your own infix ops:
(n * n-1)
=> (* n (- n 1))
To permit arbitrary infix ops, wart makes them distinct from regular symbols. Regular symbols can only contain letters, digits, and the characters ':', '?', '!' and '_'. Infix ops can only contain other characters. Thus, the sets of 'infix chars' and 'symbol chars' are disjoint. This implies that wart won't let you define some traditional lisp names that you might be used to:
def (<>) (a b) ; def <> (a b) would become <> def (a b)
(~iso a b)
wart> (1 <> 2)
To create multi-word symbols, use underscores or camelCase. I'm trying out capitalizing globals.
*global* ; I would just say Global
=> (- uppercase (- char p)) ; probably not what you want
(char> a "p")
=> ((> char a) p) ; probably not what you want
While regular symbols can't be used in infix mode, infix ops can be used like regular symbols.
To use an infix op in a higher-level function, wrap it in parens:
(+ a b)
=> (+ a b)
Infix operators can coexist with paren-insertion:
(map ++ '(1 2 3))
=> Error: map is not a number
(map (++) '(1 2 3)) ; hello haskell!
=> (2 3 4)
However, if your infix expressions need multiple lines, ask if they're worth
doing in infix. The following is actually harder to read in infix:
b+c * d
=> (+ a (* (+ b c) d))
I prefer to use infix only for simple expressions with short variable names. And I never use infix in macro expansions. After all, macros are the whole
reason we have s-expressions.
Comments, questions, criticisms? I'm wary that the interpreter is getting more complex, so this might be temporary. One open question: Can we represent some ssyntax in infix? ':' and '&' in particular seem like they should become infix operators, but there might be weird interactions with precedence. A more immediate issue is that I would lose keyword symbols like :a.
I'm unsure whether it's a good idea to use infix for assignment; prefix seems to make mutations more salient. I'm also keeping equality checking in prefix because I love the name iso so much :)
 http://github.com/akkartik/wart/tree/79476f0d230d1c5eb6b20ebc116507e0a12785de#readme to be precise.