At 09:01 PM 10/23/00 +0100, Simon Cozens wrote:
>On Mon, Oct 23, 2000 at 03:37:02PM -0400, Dan Sugalski wrote:
> > Oh, without a doubt. I'd actually like to get things building such that
> the
> > four main modules--parser, bytecode compiler, optimizer, and execution
> > engine--are in separate shared libraries, and dynamically replaceable. (or
> > at least done with a quick relink)
>
>Yes, yes, yes, yes, yes, yes, yes, yes, yes. Incidentally, I think that's a
>good idea.
Really? You seem a little ambivalent.
The one thing that just occurred to me is that we're going to need to
support multiple interpreter targets simultaneously. Having the back-end
emit C source isn't going to get those BEGIN blocks very far. :(
> > (Or a C source module, or ties into the GEM
>
>The Atari ST to my right just perked up.
:) I expect the one I dropped off at the Salvation Army probably did too.
In this case GEM is DEC's compiler back-end for their alpha machines. It's
a sweet little optimizing back end.
> > What's this piece do that B::C or B::CC don't do? I'm confused here.
>
>It doesn't embed an interpreter. It outputs "native" C.
Yerk. That must make string evals rather fun.
Runtime string eval, do, and require are a serious pain in the butt.
They're the one set of things that'll force a real interpreter into a program.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
