Front page | perl.perl6.internals |
Postings from August 2001
i was musing about the parrot last night and came up with an idea. what about writing some of the perl ops in perl itself (or in hand coded parrot assembler)? the origin of this, of course, is gnu emacs where many of the common functions are written in lisp and not c. now i fully expect most of the parrot ops will be written in c for speed. but some ops are not known for speed and may be harder to write properly in c than in perl. in particular the do/require/use ops spend most of their time doing i/o and calling eval. but they do some other stuff like searching @INC, updating %INC, etc. all of that can be easily coded in perl but would be a pain to do in c even with a better internal api. the slower speed won't matter since much of the work is i/o and eval and only the side stuff will actually be done with perl ops. the eval op will be in c (or actually perl will do the parsing). also parrot and perl will have ops for handling i/o so why have the internals use a special API to do that. we can write the i/o parts of those file ops in perl/parrot and simplify the i/o and its api. this is even more true with the idea of async file i/o in the internals. by isolating that to ops, it becomes easier to integrate and to support various platforms. we only have to write async i/o code for a parrot op api and then let the rest of perl use it. just another musing, uri -- Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com Search or Offer Perl Jobs -------------------------- http://jobs.perl.orgThread Next