On Mon, 2002-09-09 at 17:52, Nicholas Clark wrote: > On Mon, Sep 09, 2002 at 05:36:42PM -0400, Aaron Sherman wrote: > > Correct in as far as it goes. The more general answer is that one of the > > goals of this re-write (as I was lead to believe) was that the Perl > > internals would be maintainable. If we write the well over 150 Perl 5 > > builtins in Parrot assembly, I think we can kiss that wish goodbye. > > This may sound a bit arm wavy, but when I'm off messing up the core of > perl5, I don't find the perl5 ops are the maintenance problem. > Most of the op functions are quite small (partly due to the use of macros) > but they are all nicely self contained. (And all in 6 (4 before 5.8) source > files, out of a total of 36 source files)
Keep in mind that the majority of Perl 5 builtins are of the form: ....munge parameters... ....call libc function of same name... ....munge return values.... In Perl 6 those will mostly be the same. Many of them will be moved out to modules (e.g. the filehandle functions) but many others will remain in the core (e.g. chdir, getppid, etc) and simply be wrappers around the C functions. When the general-purpose interface for C is defined, these functions will be implemented in a fairly short period of time. Those that are left are internal Perl utilities that I break down into several categories: string, math, list, internal and misc. Of these, about 30-50% will probably be pure Perl. Another small percentage will be assembly wrappers that call a one-for-one parrot function (e.g. exit). The rest will be a complex mix of Perl and assembly (e.g. sprintf which is mostly Perl, but needs assembly for low-level type conversion). > Although my biased opinion is that probably best to write the perl builtins > as tidy C code rather than parrot assembler. But I know C better. Yeah, that would be ideal for speed. I am willing to concede that that's the way we'll have to go for some things, eventually. However, until we have a pure Perl library (or as much so as we can), I don't think we'll know where we need the speed boost most. What's more, this will force the compiler to optimize as strongly as possible, which can only benefit users. -- Aaron Sherman <[EMAIL PROTECTED]> http://www.ajs.com/~ajs
