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
Is there any way in PASM to determine whether or not two PMC's share the
same memory address?
That is, for example, given the following IMC snippet:
.sub _eq
.param pmc arg1
.param pmc arg2
.local int retv
...
...
.pcc_begin_return
.ret
13 matches
Mail list logo
