Larry's already said (from memory) that the distinction between ops and
subs should be minimized or eliminated.
That, together with the desire to keep parrot fairly language netural,
leads naturally to having 'heavy' ops actually be be subs.
Tim.
On Fri, Aug 17, 2001 at 06:02:44PM -0400, Uri Guttman wrote:
>
> 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 --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
> SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
> Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
