Re: Optional static types for Lua - experimental derivative Ravi

[Marc Balmer <marc@...>]

Am 18.01.15 um 22:10 schrieb Leo Romanoff:
> On Sun, Jan 18, 2015 at 11:27 AM, Richard Hundt <richardhundt@gmail.com
> <mailto:richardhundt@gmail.com>> wrote:
>
>     > Well the objectives are very different I think. I am looking to
>     > improve efficiency of certain operations. So the static typing is for
>     > that purpose. Therefore the features I intend to support will be a
>     > subset of above. For example, as of now I have no intention to provide
>     > syntactic support for classes or interfaces. Also no concept of union
>     > types.
>
>     Ah, okay, hence the additional ops. That's got me thinking: wouldn't
>     it be feasible to do run-time instruction specialization without the
>     need to add syntax (so you'd patch in your new ops dynamically)? If it
>     worked though, you could run vanilla Lua modules and perhaps get a
>     performance boost. Maybe that's a ton of work though without
>     substantial gains because recording, narrowing/widening overhead might
>     be too high to be beneficial. Dunno. Just an idle thought.
>
>
> Do you mean something like this?
>
> "Optimizing Lua using run-time type specialization"
> https://www.complang.tuwien.ac.at/anton/praktika-fertig/schroeder/thesis.pdf

How is adding type checking, in any form, optimizing Lua?  Isn't it one 
of Lua's great benefits that it is actually not statically typed?

In my experience, with a reasonably large code base, Lua not being 
statically typed is much more of a benefit than a defect, so I wonder 
why this idea of making Lua statically typed pops up from time to time.

Michael Schröder starts his text with claiming that "Like other 
dynamically typed languages, Lua spends a significant amount of 
execution time on type checks.".  Is that really the case?  Are type 
checks really using a lot of CPU cycles?  I have my doubts, but I have 
not done the research.