|
Am 07.04.2014 16:51 schröbte John Hind:
Date: Mon, 7 Apr 2014 13:05:26 +0200 From: steve donovan <steve.j.donovan@gmail.com> Subject: Re: mathlibBut, it is very _convenient_ to have the Lua core implemented in C. Otherwise the build gets involved (first build luac, then compile Lua bits, use bin2lua, recompile....) and I do appreciate that the Lua build is such a straightforward makefile. That feels like a good pragmatic argument.The core, yes, but the libraries not so much. Mathlib could be 'math.lua' shipped as a text file and 'require'ed as with any other Lua library.
But why should it? Is there anything wrong with the math functions in libc? One nice thing about Lua is the easy interfacing with C. C is the ultimate library implementation language: runs almost everywhere, and pretty much any programming language can bind to a library written in C. Why duplicate the effort and reimplement the math functions in Lua?
But the idea *could* be taken further. The parser could be done in Lua and shipped as an include file containing a 'C' array initialiser in the standard source package. Might be necessary to have different versions of the include file for endian issues, but that is just a compiler switch. So out-of-the-box you can build the runtime and use that to rebuild the parser if you want to do that.
IIRC, the bytecode also depends on the size of a `size_t`, so you probably get at least 4 different variants (maybe more in Lua 5.3 with 32/64-bit integers and floats).
But that is much more ambitious that I intended to suggest for the moment. Just migrating the libraries, incrementally, to Lua would be a good evolutionary path and since we are discussing mathlib, that could be a gentle toe in the water!
Most standard Lua modules can't be migrated to Lua completely, and I'm not sure I like the idea of mixed module implementations (part C, part Lua).
Philipp