Re: table library changes (was Re: table.new in 5.3?)

[Sean Conner <sean@...>]

It was thus said that the Great John Hind once stated:
> > Date: Wed, 27 Nov 2013 17:16:02 +0000
> > From: Justin Cormack <justin@specialbusservice.com>
> > Subject: Re: table library changes (was Re: table.new in 5.3?)
> 
> > Interesting, but shouldn't the stuff that can be implemented in Lua be
> > removed form the language? ;-) Adding more C support for things does
> > sounds good though.
> 
> Yes, this is the crux of my argument.
> 
> 1. There are currently some fairly large chunks of C code in the standard
> libraries which are accessible from Lua but not via the C API. The string
> library is probably the largest culprit here, but sort in the table
> library is (may be) another example.

  So you're saying that the string library should be written in plain Lua
then, right?  Or are you trying to say that the C API lacks access to the
string manipulation you get from Lua?  I'm not sure I'm following your
argument here.

> 2. "The Language" could include standard libraries implemented in Lua.

  I'm looking over the standard functions that come with Lua.  The coroutine
stuff has to be in C, as it mucks with the Lua VM.  The io library also has
to be in C, given it's a wrapper around the Standard C Library (which itself
provides a portable interface on IO).  I can't see the math library being
written in pure Lua, having read the horrors that await implementers in
several books [2]---the work has already been done.  The os library, again,
interfaces with the underlying operating system via the Standard C Library.

  The base functions, about half appear to be a Lua interface into Lua
itself (much like the debug library).  Yes, some can probably be written in
Lua (such as loadfile(), but that would rely upon the io library anyway;
pairs() (upon coroutine.* and next()) and ipairs (again on coroutine.*)) but
I think it's less than you realize.

  Experiment:  Create an empty Lua state in C:

		L = luaL_newstate();

  Implement as much of the Lua standard library in Lua as you can.  Now test
on Linux, Mac OS and Windows.  

> 4. Benchmarks should not have the last word between C and Lua - if you
> take that position, why use Lua at all? 

  I use Lua because it makes development faster.  Granted, I had to write a
buttload of C code [3] to help my development.  And if performance is an
issue, I know I can drop down to C [4].

  But if I'm curious enough about performance, yes, I will do silly
microbenchmarks to get a feeling for performance---for instance, creating a
coroutine is cheaper than spawning a thread or process, so I don't feel so
bad about spawning a large number of them in a networking project at work
[5].  

  -spc 

[1]	The configuration file.  

[2]	_Numerical Recipies in C_.  _The Standard C Library_ by Plauger. 
	_ Seminumerical Algorithms_ (volume 2 of the Art of Computer
	Programming) by Knuth.  

[3]	Yes, I wrote my own versions of LuaSocket and luaposix, but part of
	that is my attempt to learn Lua, and my finding the API of LuaSocket
	and luaposix questionable.

[4]	Hey, a C compiler as a Lua module:

	https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.c

	And a wrapper to load Lua modules from C source code:

	https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.lua

[5]	Using an event-driven architecture and resuming a coroutine per
	event.  Makes writing the main logic of the program straight
	forward.