Re: mathlib

On Sun, Apr 6, 2014 at 7:16 PM, Sean Conner <sean@conman.org> wrote:

It was thus said that the Great Coroutines once stated:
> On Sun, Apr 6, 2014 at 2:35 AM, Kevin Martin <kev82@khn.org.uk> wrote:
>
> >
> > On 5 Apr 2014, at 11:32, Michael Richter <ttmrichter@gmail.com> wrote:
> >
> > In this model there would be a Lua language kernel. It would be the Lua
> > language (obviously) and the *absolute minimum* set of features necessary
> > for implementation of that language. *Everything* else (including much
> > of the functionality on strings, lists, math, debug, etc.) would be farmed
> > out to third-party (even if "blessed" third-party) libraries.
> >
> >
> > Although I'm not particularly fussed about whether these functions stay or
> > not, I would definitely support their movement into lmathx as a step
> > towards this Lua Kernel approach detailed above.
> >
> > I believe (maybe wrongly?) that people who use Lua for application
> > development, almost always have to use some libraries not distributed in
> > stock Lua, as the included functionality is limited. If people are happy to
> > include external libraries, then why not an external, greater capability
> > math library?
> >
> > Is the real question not
> >
> > "How many people who only use Stock Lua, or can't use lmathx, require
> > these functions?"
> >
> > Thanks,
> > Kevin
> >
>
> It's kind of been suggested before -- but I would love this if the only
> "standard library" compiled into Lua were bindings for the C API. That
> way, the rest of the core libs from the table to string libraries could be
> rewritten in just Lua and require()'d in if you wanted. Lua's most core
> functionality (imo) is:
>
> 1) lexing and compiling Lua source to bytecode
> 2) interpreting Lua bytecode (the VM)
> 3) embedding itself in other applications (the C API)

Easy enough to play around with. You just need the following files (list
from 5.1---probably similar to 5.2 and 5.3):

lauxlib.c
lapi.c
lstate.c
ldebug.c
lobject.c
ldo.c
lgc.c
ltm.c
lvm.c
ltable.c
lstring.c
lzio.c
lfunc.c
lmem.c
lopcodes.c
ldump.c
lundump.c
llex.c
lparser.c
lcode.c

That fulfills all three options you listed (modulo require). To get
"require" you will also need loadlib.c. The rest are not required to run
the actual Lua VM.

> I think it'd be much cleaner and easier for people to help improve the
> standard libs from obvious mistakes if they were written in Lua, with an
> arguably negligible performance hit.. Indexing strings could be
> nightmarish if one wanted to implement the string library in Lua, though..
> Anyway, people have been talking about removing some of the math
> functions, and I rarely see people use things like string.reverse() -- I
> vote take it a step further and make it so "require
> 'table/string/debug/etc..'" becomes the norm.

So, go ahead and have fun 8-)

-spc (But there's no print ... )

I was saying that if the proposal to move Lua to a kernel-like design were taking serious, it'd be good to orient the default makefile toward building out these 3 functionalities -- and then including the standard libs like 'string' in corelibs/ dir or something (libs/{string,table,coroutine,debug,etc..}) to be installed and loaded as needed. It would suit the purpose of staying minimal and (extendable?), heh. I feel like the mathlib has gotten a lot of unreasonable scrutiny and gutting proposals lately. The (mathx?) lib is done by an upstream dev of course, but it's easier to trust what is distributed with Lua as it gets more testing/scrutiny. I don't like the idea of mathlib losing some of its features unless they were still available but could be avoided without recompiling Lua.