Types with functions would be a huge step. You could do it without too much syntactical/compiler changes by something like the ideas below. All it ends up being is a syntactic rewrite of a function call, if you don't use subclasses. Obviously the compiler needs to know what the type is of the object it is acting on but it must know that anyway.
type demotype
<stuff>
endtype
then
function method_dosomething_demotype(self ref as demotype, param1)
<stuff involving self>
end
(or even function demotype:dosomething(param1) with a little bit of sugar)
then you could have:
test as demotype
..
..
test:dosomething(42)
this last line is just a function call - it would just be syntactic sugar for
method_dosomething_demotype(test,42)
this would give you a very simple OOP system. Then you have subclassing, which could be done via types within types messily.
type subtype
oldclassstuff as demotype
(new members here)
endtype
so that if the syntactic sugar failed (e.g. there was no subclass subtype method donothing) it looked in the superclass and applied the subclass method of demotype to the oldclassstuff member.
What you don't have is any virtual functions/polymorphism type stuff. This may not even be possible in the bytecode which looks to be entirely static in nature. A basic (ahem) question is can the system do call func$(a,b,c) ?
And regular expressions would be nice. Maybe not bother with the whole lot - lua has a simplified version which works for most code requirements.
I would think it's part of the lua library code (e.g. it's written in C) so you might just be able to use it as it is with a bit of tweaking. lua is designed to be embedded in other programs without doing the license-virus thing that O/S code often does. Could be new facilities for pretty much no work - pass it two strings and an array of strings for the return groups and return a "boolean".
