On Sat, 2001-11-03 at 22:11, Gregor N. Purdy wrote:
> Brian --
>
> > > None of these are issues with the approach I've been working on /
> > > advocating. I'm hoping we can avoid these altogether.
> > >
> >
> > I think this is a cool concept, but it seems like a lot of overhead with
> > the str
t people won't do it.
So I suppose we have three sorts of opcode libraries:
1) The core set. These must have constant numbers that don't change over
the life of perl.
2) The core library set. These will have reserved sets of opcode numbers
and shouldn't change either. (Stuff like
--- "Gregor N. Purdy" <[EMAIL PROTECTED]> wrote:
> Brian --
>
> > > None of these are issues with the approach I've been
> working on /
> > > advocating. I'm hoping we can avoid these altogether.
> > >
> >
> > I think this is a cool concept, but it seems like a lot
> of overhead with
> > the st
On Sat, Nov 03, 2001 at 09:40:14PM -0500, Gregor N. Purdy wrote:
> Let me try to illustrate what I'm thinking a little more clearly. The
> program:
>
> .use core
> set I0, 5
> set I1, 37
> add I2, I0, I1
> print I2
> print "\n"
> end
>
> would have an opcode_table in the pac
Brian --
> > None of these are issues with the approach I've been working on /
> > advocating. I'm hoping we can avoid these altogether.
> >
>
> I think this is a cool concept, but it seems like a lot of overhead with
> the string lookups.
I'm hoping we can keep the string lookups in order t
On Sat, 2001-11-03 at 21:40, Gregor N. Purdy wrote:
> James --
>
> > We're going to have to think about assigning static opcode numbers,
> > instead of the current order-defined. For one thing, we're looking at
> > perpetual bytecode compatablity (no?). Th
James --
> We're going to have to think about assigning static opcode numbers,
> instead of the current order-defined. For one thing, we're looking at
> perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
> need to:
> 1) Define an orderi
Hey all.
We're going to have to think about assigning static opcode numbers,
instead of the current order-defined. For one thing, we're looking at
perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
need to:
1) Define an ordering on things like open(i, s
