If you can fix the binding of an operator (left-associative or right-associative), you can handle the overloading quite naturally using a form of operator overloading.

E.g.,

foo + bar
becomes foo->+(bar)
falling back on some generic "+" function if foo->+ does not exist.

I'd try just getting it working first before worrying too much about getting it "optimal" – it might turn out to be not-so-bad, you know.

Actually by overloading i meant default overloading of builtin operators not user defined ones. I am trying to avoid inspection of types as much as possible at runtime which deviates heavily from how most LPC interpreters work.



Well I am not sure how long things like this typically take. I am hoping perhaps in the next two months to get this finished but I am not sure how feasible that is. This is obviously for a testable simplified prototype lacking full features. I suspect writing a VM thin layer will take several more months to get full functionality close to that of a server(if i get that far).

Why does it make a difference if the operator is built-in or not? If you know something about the type at compile time, you can know if it has an overridden operator. If you don't know anything, you have to do the full operator look-up anyhow.

Out of curiosity, why are you rewriting all of this stuff if there are already LPC interpreters out there? Are you adding something to the LPC language, beyond type checking?

It's a very good question :-). Mostly I am doing this for personal reasons since it is a hobby anyhow- also there having been several different proposals recently discussed about how to get around the somewhat restrictive licensing that most LPmud servers have. Also from a technological perspective I am curious how well LPC can work with a JIT system and garbage collection. In terms of language additions, I had a number of extension proposals, but during discussions with others on I3 (intermud 3) most of the rest of the group didnt express much interest in them. Some language extensions I did consider were-

adding recursive data types…
adding type parameters….
moving towards syntactical "class construct"
adding unification style pattern matching and so on. (transparent types + opaque when you need them)

Most likely I might save some of these ideas for a followup project which would not be close to compatible with existing mudlibs where I might recycle the experience of building the first system and the probably a fair amount of the backend. If I had a free choice I would choose a less tricky language like a typed scheme system with OO extensions built in.