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
At 09:57 PM 11/3/2001 -0500, Brian Wheeler wrote:
>On Sat, 2001-11-03 at 21:40, Gregor N. Purdy wrote:
> >
> > 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 lo
--- "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?). This isn't really a Big Deal, but we
>
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 ordering on things like open(i, s|sc,
