Re: A guide to building Lua modules

[Sean Conner <sean@...>]

It was thus said that the Great Coroutines once stated:
> On Wed, Apr 16, 2014 at 1:09 PM, Sean Conner <sean@conman.org> wrote:
> 
> >   I have to ask:  What attracted you to Lua?  Why not use Ruby, which has a
> > history of allowing much that is mystical, implicit and convenient?
> 
> I was attracted to Lua by its speed initially, I used to be one of those
> crazies who would periodically review the Computer Benchmarks Game and
> scout out the languages that had the edge after C/C++/Ada/Java.
> 
> The argument is, Lua can't gain every feature if it costs us speed -- I
> recognize that.  The issues I usually hate Lua for are things like locals
> being allocated for at compile-time

  Fixing this in Lua would be a massive internal overhaul of how the
compiler works, and most likely make Lua slower.  The reason locals are
faster than table lookups is that locals are really VM registers, which
also explains why locals can't be declared at runtime.

> and varargs not being easier to store/handle

  Yes, I could see the appear for a bit of syntactic surgar to make using
varargs nicer.  Yes, it might be nice to do:

	for i = 1 , #... do
	  print(...[i])
	end

instead of:

	for i = 1 , select("#",...) do
	  print(select(i,...))
	end

but ... that might lead some to believe that ... is a table (it isn't) and
why can't you do:

	table.insert(...,"foobar")

or even

	table.sort(...)

  Yes, you can document that ... is a special thing and that the three
ways you can us it are:

	function(...)
	var = #...
	var = ...[integer_index]

  Personally, I wouldn't mind seeing #... and ...[] and removing (or
obsoleting) select() (one less function to pollute the global namespace). 
But I'm not going to get all upset over this if it doesn't happen (there are
things I would love to change about C, but I'm realistic enough to know that
I have as much chance as Cnut stopping the waves).

> and Lua not being oriented for preemptive threading 

  If by "preemptive threading" you mean "switch coroutines without the
coroutine itself callling coroutine.yield()" then that implies that there's
something outside of Lua that can perform the switch (or somehow tell Lua to
perform the switch).  But that's not what coroutines are (which is why they
are cheaper and faster than an actual thread).

  But if by "preemptive threading" you mean "share a Lua state between OS
threads" then there is hope.  All you need to do is provide an
implementation of lua_lock() and lua_unlock() and recompile the Lua core
with these functions.  In fact, if you want the previous definition
(preemptively switch coroutines) you'll probably need to do this anyway, as
by default, the Lua state isn't thread safe.  

> or message-passing without serializing objects.

  There are several Lua modules for serializing objects.  I'm not going to
fault Lua for this, as this isn't within Lua's target domain (it's domain is
"embedding a language interpreter into an application").  

> >   And, what do you mean by "Lua's growth?"
> 
> We're just now getting some minimal handling on utf8. :\

  There are a lot of languages in the same boat.  Anything else?

  -spc