On Monday 10 September 2001 11:16 am, Dan Sugalski wrote:
> No. We don't need perl to test the interpreter. Parser and compiler, yes,
> interpreter no.
The code that we are writing in assembler is Parrot opcode that we would
expect a Perl parser and compiler to spit out. (That's all I'm saying....)
>
> >Certainly, register creation, memory allocation, garbage collection, and
> >opcode dispatch are definitely within the purview of Parrot. However,
> > the opcodes' code themselves aren't - they're provided by the language.
>
> Nope. The core opcodes are provided by the interpreter. A branch is a
> branch is a branch, no matter what language generated it.
Yes, but what are you defining as core opcodes? Branches, okay. Basic
math, okay. Basic string..., um, okay. Call and method dispatch, okay.
Everything else in Perl that will eventually be an opcode? I hope not.
> >Things to keep in mind. (And another reason why it's good to have
> > Namespace Police.... :)
>
> For which reason we have brainwashed^Wrecruited Ben, it seems. Keen!
> (Smile and wave to the OMCL, Ben... :)
Like I said, just things to keep in mind. There's a slight difference
between designing and coding Parrot as an interpreter backend, and coding it
as a backend to Perl that other languages can use. (I'm in favor of the
latter, though public opinion seems to favor the former.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
