On Fri, Aug 25, 2000 at 09:12:32AM -0400, Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and Michael G Schwern <[EMAIL PROTECTED]> wh
> ispered:
> | PS The idea of adding acos, asin and tan is good.
>
> You just answered your own question. It is very difficult to add new
> functions to the core. It is very easy to write new modules. Doesn't it
> make sense that if you have to use Math::Trig to get to acos and friends,
> you might as well make the language definition clean and say all of acos
> friends should be in that module, not some in the core?
Actually I was suggesting that acos, asin and tan be added to the core.
Most likely, splitting this out into a module wouldn't make anything
much simpler. To get anything like the performance math functions
need, Math::Trig could not be written in plain Perl. It would have to
be written in C or XS (or whatever perl6 winds up being written in)
probably calling the system's math libraries and still dragging in all
the basic problems of a core patch and configuration.
> That's the basic goal behind my RFCs for moving things to modules. In
> general, I hope to make the language cleaner, easier to learn and use, and
> easier to extend. If at the same time the language became better
> performing because of a removal of some of the core, all the better. As
> you say, 200 lines isn't much. But combine that with the IPC, the
> environment, the system, etc it all adds up.
I think I basically agree with tchrist here. This is nickel and dime
stuff. Cutting out the math functions isn't going to do squat. IPC
and the system... that might do something, but Dan pointed out that it
doesn't amount to much either.
I think we should back up and reconsider what the intent of this RFC
is.
If the intent is to make perl more maintainable and easier to patch,
I've already commented on that. You're just shuffling code around.
And only a small fraction at that.
If you wish to make perl smaller and faster, just tearing things out
isn't going to help. Its hit-or-miss optimizing. You could remove
half the core functions and find out you only gained 5%.
Like all other optimizing attempts, the first step is analysis.
People have to sit down and systematically go through and find out
what parts of perl (and Perl) are eating up space and speed. The
results will be very surprising, I'm sure, but it will give us a
concrete idea of what we can do to really help out perl's performance.
There should probably be an RFC to this effect, and I'm just visiting
here in perl6-language so I dump it on somebody else.
exit('stage' << 1);
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
When faced with desperate circumstances, we must adapt.
- Seven of Nine
