At 11:37 PM 8/22/2001 +0100, Tim Bunce wrote:
>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.
Yup. That's definitely the plan. The only issue at the moment (and I'm not
sure how big of one it is) is whether we generate native functions on the
fly for opcode functions (and any other function use, for that matter) or
use a generic dispatch function written in C that dispatches to the perl
function.
I think we're going to need to generate native functions on the fly (yay,
self-modifying code) in which case we might as well just do that
everywhere, but it definitely makes some things a little trickier. (Like we
have to have platform specific code everywhere)
>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
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
