You could specialize for primitives, e.g. under the hood generate complexExpression_int() and complexExpression_ref(). It wouldn't be too bad in terms of code size, because you only have to specialize primitives, and all reference types can share the same implementation.
Re:Objects All the Way Down
by david-given on Friday November 27, 2015 @09:35AM
(#10637454)
Yes, that'd be the obvious thing to do, but I think right now it doesn't (I could be wrong; I haven't looked at the code for ages).
I did at one point try to specialise everything. The results were hilarious...
var a = cons(cons(cons(cons(empty, 1), 2), 3), 4);
As the left-hand-side of each cons was a slightly different type, it ended up generating four different versions of the cons function!
What this means is that at the semantic level, the language doesn't distinguish between objects and scalars, so avoiding the horrible schizophrenia that languages like C++ and Java do --- you can subclass an integer just as easily as you can anything else. Performance is really good, too, mostly.
The downside is somewhat unpredictable behaviour due to invisible boxing and unboxing. e.g.:
The type inference will see that complexExpression() is being called by both a scalar and an object, which means that x needs to be implemented as an object pointer, and the literal 4 needs to be boxed. This means the calculations inside complexExpression() will end up being a lot more expensive due to boxing and unboxing overhead.I should readdress this at some point; it was a really nice thing to write code for.
http://cowlark.com/cowbel/example.html