Earlier quoted context omitted.
Interesting language, and looks fairly concise to write. I imagine shoehorning all numbers into doubles makes for slower integer code. Also a shame you included pervasive null. Wren looks straightforward enough that you could have a static type system without losing any expressiveness. Have you considered that?
> I imagine shoehorning all numbers into doubles makes for slower integer code. Maybe, though in a bytecode-compiled, dynamically typed language, my hunch is that using doubles for everything is actually faster. If I had separate integer and float types, all of the arithmetic operators would have do runtime type tests to handle the different combinations and conversions. I could be wrong, though. Either way, only hav…
Perhaps. I suppose this dovetails with my preference for static types with optional dynamic behaviour, and not the contrary default which seems to be your position.
> I'm interested in trying to layer an optional type system on top of it, and I tried to design most of the language and core library such that it's amenable to that.
Cool. I think Wren is simple enough that basic type inference should be straightforward and complete, and anything more difficult just infers a top/'dynamic' type. A trivially correct type inference algorithm then just infers type 'dynamic' everywhere, which recovers Wren's current semantics. Then you incrementally add more specific rules where you can, ie. simple data flow from constants will generate more efficient string, floating point and integer code.
That would be enough for a decent speedup on most programs. If you want to type check arbitrary objects (or at least avoid method-not-understood), you can use something like "Type Inference for First-Class Messages with Match-Functions" [1] or the even more general first-class labels [2]. I believe first-class labels are more general than Wren's semantics.
[1] http://lambda-the-ultimate.org/node/4808 [2] http://lambda-the-ultimate.org/node/174