If a type system can be easily escaped, does it really offer you much?<p>If it's still transformed to run in the runtime of a late-bound dynamic typed language where the types can't be used by the compiler to produce optimized code with early-bound type function/method dispatch, does it really offer you much?<p>I guess I don't really see optional static typing as giving the best of both worlds, as it cannot deliver on what a good static type system can give you.
This is interesting, but the benchmarks suggest that LuaJIT usually does as good, if not better. So there doesn't seem to be much benefit to the static types, at least performance-wise.
I often wonder if the whole idea of "typing" is the wrong decision in language design, if we shouldn't come up with something better. Dynamic languages are often trying to insert some form of typing. Static languages are often trying to inject tools for heterogenous collections. It's clear there are advantages to both approaches, yet a languages is usually definitely one or the other, which seems limiting. Not that I have a solution, but perhaps breaking programs into primitive types or lack thereof isn't the right approach to the abstraction.
Lua is a great little language.<p>You gain the most from this, if you stay lua-native for the entire time- doing all calculations in the lua-vm, and are not depending to much on calls into the underlying c-programm (happy cache misses :( ).<p>Is there a optimization, that starting from the calls, creates dependancy trees, which allow to bundle away the calculation and calling of the call into seperate (pre-existing Tasks), in such a way, that the Result for simple-calls is in when the programm reaches the call?