lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Mon, Apr 7, 2014 at 10:50 AM, Philipp Janda <siffiejoe@gmx.net> wrote:
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: mathlib

But, 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


Er, I guess it would make more sense as several .so/.dll's.  math.so, string.so, table.so, debug.so, ... I forget why but I think making the core libs depend on dlopen+dlsym (for luaopen_*) behavior was avoided for a big reason.  Still wish the were separate to fight this math-gutting discussion.  The only function we can all agree on removing is math.pow()