Simple, Implementing a built-in numerical analysis library is uncommon on a general purpose programming language. Regarding to the Classpad, including that lib will make CPLua more unstable (?), possibly slow
I don't think that CPLua would be less stable or slower... However it would need a lot of work to adapt it properly, to test it, to write the documentation...
And more annoying: CPLua is already (very) large
I'd like to avoid increasing its size for unnecessary stuff
btw: Orwell, what about adding (if it's possible without a lot of work) a communication protocol on CPLua?.. some functions to send and receive data using the calc-to-calc cable?. Some clustering would be amazing.
I've had it in mind for a long time now...
btw2: How goes CPLua 0.9?
Well, my studies are currently more important... But don't worry, I'm not dead yet
I think Orwell said that he is going to make CPLua able to accept user plug-ins. So the best gift that he could give to CPLua users! so there wouldn't be any argument about adding any special library to CPLua.
Hmm... it's not like each user could choose the plug-ins he wants to load into CPLua.
What I meaned is that CPLua is now flexible enough to create some new utilities (project manager, on-calc documentation, ...) besides
the text editor and the Lua interpreter which are embedded into CPLua (but which are completely different things). And unfortunately the ClassPad does not support dynamic libraries, so all those "plug-ins" must be activated when CPLua is compiled, and you cannot remove them after that
And as I said, CPLua is already quite large, so we should avoid adding too much "gadgets" in it