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) The writhing mass of yuck comes from the interaction of the bits in the various utility functions that they call in the other 26 or so files. Plus the 2 files of the regexp engine, and the 2 files of the parser which I attempt to avoid lest I go insane. Hence I don't think that writing the perl builtins in parrot assembly (or at least the majority that really need to go really fast) would be a maintenance nightmare. Although being able to write them in perl and having an inliner and optimiser that is good enough to produce results better than calling out to general purpose parrot assembler would be nice. 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. Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
