Re: mathlib

[Ralph Hempel <rhempel@...>]

Coroutines wrote:

<snip>
> 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.
</snip>

There is a fine line between providing standard core Lua functions (especially 
in string/table/math/...) that are written in C and baked in to the standard 
product, as opposed to writing them in Lua, and it is this:

	Having some core functions written in Lua lowers the barrier to
	changing the implementation of those functions.

Some would say - big deal! I want to change how function XYZ works because those 
silly Lua authors did not listen to my suggestions the last time we talked about 
feature XYZ.

I hate to bring age and experience into this discussion, but ... Those of us old 
enough to remember Forth will also remember that it was a language where it was 
easy to lift the hood and make it do what you want. The result was n variants of 
Forth where n approached the number of Forth programmers after a decade.

I'm exaggerating of course, but I don't want to make it easier than it is now to 
change the core libraries like string/table/math that programmers expect to stay 
the same between versions.

I have implemented Lua on very resource restricted platforms, and its footprint 
is quite small. I ended up using simple float implementations of the math 
functions, horrible accuracy but good enough. The key point is that I included 
as much of the documented standard as practical on the platform.

In fact, the target was so restricted that I made math a loadable library.

While I understand minimizing the feature set, bug surface area, etc, let's 
leave mathlib as is (except maybe remove pow) and leave the implementation of 
the "new and improved" math library as an add on that can be loaded.

I guess I just made an argument for loading the standard math library too :-)

Ralph