Overloading Ideologies

I'm up late programming (yes, even as I post this blog) and currently shifting perspectives on a language feature that I've been at odds with for years. If this doesn't sound interesting to you yet, maybe you'll find amusement in my nerdy attention to syntactic detail.

The scripting language I'm writing has been both the largest project I've undertaken as well as the most revealing about the world of coding in general. Both by inventing and "borrowing" language features to design my ideal code parser and environment, I've been actively comparing each iteration of my design with half a dozen well established giants (C++, Java, C#, Python, Ruby, and Haskell). I often push commonly expected features (like function calls in expressions) out of the specifications when they don't fit my current coding philosophy (or mood). More often than not, those features creep back in when I find myself missing them and forget why they were so undesirable in the first place. Though my notes cover controversial design decisions in detail, after a couple weeks they start to look like passionate forum posts from whiny amateurs "Why can I define this as read only but not write only?" or arrogant attempts at controlling coder's thoughts "Abstract classes can't have member data". Anyway, a recent wave of inspiration tore through my hesitation to implement one of my most hated language features: operator overloading.

Magic language features are dangerous territory, providing functionality to key parts of a language (like concatenating strings in Java) but restricting the coder to those built in mechanisms. It makes perfect sense to add two linked lists, but Java won't do that.

So why do I hate overloading operators if I want to put some of that magic in the coder's hands? Without giving them access to all the operator inner workings, it's like handing a chainsaw to an orangutan. "This is specifically designed to cut wood, but go massacre whatever you want with it". Overloaded operators have an aura of mischief, trespassing on everyone's expectations of how adding should work. So, it's common practice to ignore the feature when it exists and stick to member functions.

Well, what if operators *were* functions, with no magic whatsoever? That's my aim with the scripting language. There are no base types, thus no expression operators that come magicaly packaged with the compiler. Every type, ints included, are actually added to the program in a library instead of coded into the parser. And that library code is written in the script and freely available. The result: thinking of every single operator (even adding two numbers) as a customized, code defined expression. Operators become no different than functions. In fact, I'm leaving it open for coders to define a <|[dlf%[)w}! operator if they so please.

This could be a refreshing take on an old problem, or a feature that everyone but curious beginners ignores like a big red button. Either way, it's nice to change one's mind now and again, to live dynamically rather than statically. (Did I tell you how much I hate the "static" keyword! It's been misrepresenting scope for . . . . . . . )

Well, that's all. Go ahead and clear your head with this:
http://video.google.com/videoplay?docid=-8953743256904057853&hl=en