At 9:18 AM -0700 12/3/03, Cory Spencer wrote:
> We're already using 'eq' to perform equality testing, and in the interests
of maintaining a consistent design I would choose to stick with something
eq-related as opposed to changing it to 'same'.
eqaddr/eqval? eq_addr/eq_val? eq_address/eq_valu
> I don't think there was ever a consensus about opcode naming.
> It seems that we need this but can you give an example
> of where you are using it, just to give me some context to think
> with?
I've been implementing a Lisp interpretter (and hopefully at some point,
compiler) and was using the
L PROTECTED]
cc:
Subject: Re: Determining PMC memory addresses
> We're already using 'eq' to perform equality testing, and in the
interests
> of maintaining a consistent design I would choose to stick with
something
> eq-related as opposed to chan
> We're already using 'eq' to perform equality testing, and in the interests
> of maintaining a consistent design I would choose to stick with something
> eq-related as opposed to changing it to 'same'.
>
> eqaddr/eqval? eq_addr/eq_val? eq_address/eq_value?
So just to follow up on this thread,
Jos Visser <[EMAIL PROTECTED]> wrote:
> I would therefore vote that we keep these opcodes as verbose as
> possible. So no eq/eql/equal, but rather
> same_address/same_content/compare/compare_as_num/compare_as_string.
Or as verbose as needed [1]:
ident, eq, , _num, _string for in (lt le gt ge)
> We're already using 'eq' to perform equality testing, and in the interests
> of maintaining a consistent design I would choose to stick with something
> eq-related as opposed to changing it to 'same'.
>
> eqaddr/eqval? eq_addr/eq_val? eq_address/eq_value?
Oops, correction there - I'd forgotte
> I think this is definitely something we should do if we want to confuse
> people as much as possible :-)
This is likely true, seeing as I *still* have troubles keeping the various
Lisp eq/eql/equal/equalp's straight. ;)
> I would therefore vote that we keep these opcodes as verbose as
> possib
On Fri, Nov 28, 2003 at 10:27:45AM -0700 it came to pass that Cory Spencer wrote:
>
> > > On Fri, 28 Nov 2003, Leopold Toetsch wrote:
> > >
> > > > Op vtable Meaning
> > > > - is_same PMCs are ident
> > > > - is_equal PMCs are equivalent, holding the same value
> > > > Y cmp
> > On Fri, 28 Nov 2003, Leopold Toetsch wrote:
> >
> > > Op vtable Meaning
> > > - is_same PMCs are ident
> > > - is_equal PMCs are equivalent, holding the same value
> > > Y cmp cmp PMCs
> > > - cmp_num cmp PMCs numerically
> > > - cmp_string cmp PMCs as strin
On Fri, 28 Nov 2003, Cory Spencer wrote:
> On Fri, 28 Nov 2003, Leopold Toetsch wrote:
>
> > Op vtable Meaning
> > - is_same PMCs are ident
> > - is_equal PMCs are equivalent, holding the same value
> > Y cmp cmp PMCs
> > - cmp_num cmp PMCs numerically
> > - cm
On Fri, 28 Nov 2003, Leopold Toetsch wrote:
> Op vtable Meaning
> - is_same PMCs are ident
> - is_equal PMCs are equivalent, holding the same value
> Y cmp cmp PMCs
> - cmp_num cmp PMCs numerically
> - cmp_string cmp PMCs as strings
>
> Proposals for opcode nam
Cory Spencer <[EMAIL PROTECTED]> wrote:
> Is there any way in PASM to determine whether or not two PMC's share the
> same memory address?
Not yet. We have the vtable methods but the opcodes are missing.
We have:
Op vtable Meaning
- is_same PMCs are ident
- is_equal PMCs are equ
12 matches
Mail list logo