LispCraft

Hi, all. I finally completed Warcraft 2 implementation in LISP.
http://img859.imageshack.us/i/52320836.png/

Took me a few months, though, but mostly because I was too lazy and my DSL is still pretty buggy, has poor debugging support and long compilation times (takes about 30 seconds to reload source file). Anyway, this proves, that writing a game in Lisp is relatively easy, even for a single person.

>>79
For instance, the context of the character < in #include <frozenvoid.h> is different to the one in if (a < b). The compiler knows that < means different things in different places. Limiting yourself to a one-to-one mapping between symbols and functions is silly.

I love Vintage Nikita too.

>>79
Is that syntax based on Template Haskell?

>>81
Compiler doesn't even see #include <frozenvoid.h>, do you know?

Also,
list<pair<string,int>>

>>84
It's an example, use your brain instead of picking out the irrelevant details so you don't have to respond properly.
Wait, does Symta even have lexical scoping? It wouldn't surprise me if it didn't. Have any scoping whatsoever, I mean. You do seem that clueless.

>>81
No. Reader reads <...> as simple ("<>" (...)) and if `>` is missing, it would be a read-time error. Of course macro can treat this ("<>" (...))

>>86
Symta does have lexical scoping, but I also use it to implement OOP. X and Y in (X:1 | Y:2 | X+Y) or (X:1 | Y:2 | sum = X+Y) wont be seen outside of (...), but in case of `sum = X+Y`, (...) gives closure with method `sum`. This provides encapsulation. Packages are implemented the same way, just to make reasoning about them easier (I was confused by Common Lisp's eval-when mess).

>>87
I.e. Symta is a context free language, which should make parsing easier.

>>87
Oh, pardon me. I thought >>84 was you.
In any case, can't it treat an unmatched < as `lt` instead of an error?

>>89
No. How would you parse <A < B = C>: <(A < B) = C> or <A (<B = C>)?

>>90
<A in <A (<B = C>) has no left-hand side.
Even D < A < B = C > would work because after D it should expect an operator, not another operand.
There are also various precedence rules you could apply.

>>91
*wouldn't

>>91
<A in <A (<B = C>) has no left-hand side.
Usually <...> is part of some larger expression, like [X <A < B = C> Y]

Even D < A < B = C > would work because after D it should expect an operator, not another operand.
How about (list D < A < B = C >)? Why not (list (D < A) (< B = C >))?

>>91
What about (list < A < B = C >)? It will be parsed as ((list < A) ..)

>>90-94
Cool edge cases