Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>
>It probably would. Dynamic loading is not cheap, and having
>to do a dlopen() and a dlsym() (or a LoadLibrary() and a
>GetProcAddress()) to find out the square root of 2 is not
>my idea of a _useful_ lightweight programing language.
But if you add -lm to your perl link line then ld.so will
do almost exactly that for every run of perl even if it does not
do any sqrt()s. (Well actually only the dlopen() - the dlsym()
is done by a stub function...)
...
>
>AUTOLOAD searches are not cheap either. It can take a lot
>of stat() calls to even _find_ the correct module, much
>less load it. The average math function in the perl5 core
>is about 13 lines of C code. Eviscerating it out of the
>core would accomplish nothing.
And that is _NOT_ what is being proposed.
What I envisage is more like "overlays" of the 16-bit era -
tightly coupled binaries which are stored alongside 'perl'
in what ever place is the "easiest to find" way for the platform.
So when you see your 1st sqrt the stub function table does
in (C/perl hybrid pseudo code):
mathtable = (mathtable_t) dlsym(dlopen("$^X.math.pld"),"mathFunctions");
return (mathtable.sqrt)(@_);
_Iff_ this perl has not got them "linked in".
>
>Slowing perl down and forcing everyone to add 5 "use"
>statements to the top of every program to get any useful
>features would neither make it more useful or more fun.
This is the _INTERNALS_ list - "use" statements don't live here.
--
Nick Ing-Simmons
