what I'd like to do is to determine whether arg1 and arg2 are the SAME pmc object (not in value, but whether or not they reside at the same location in memory).
Cory Spencer <cspen...@sprocket.org> 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 equivalent, holding the same value Y cmp cmp PMCs - cmp_num cmp PMCs numerically - cmp_string cmp PMCs as strings
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 names welcome.
How does the current 'eq' opcode deal with comparissons of PMC/PMC values?
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 > > - cmp_string cmp PMCs as strings
> > Proposals for opcode names welcome.
> How does the current 'eq' opcode deal with comparissons of PMC/PMC values?
'eq' calls is_equal, so that should have a 'Y' in the table above.
> > > 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 names welcome.
> > [snip]
Well, a page could be stolen from the Lisp book by defining eq/eql/equal opcodes (though in ths case, differing from the Lisp counterparts in the meaning of the tests) where
- eq is true if both arguments have the same value (that is, both are numerically equal or both are equivalent strings) - eql is true if both arguments are the same, identical object - equal does a comparison to test if the two objects are structurally similar (ie. in the case of a PerlArray, an element-by-element comparrison would be performed to determine the similarity of the structure.)
> > > > 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 names welcome.
> > > [snip]
> Well, a page could be stolen from the Lisp book by defining eq/eql/equal > opcodes (though in ths case, differing from the Lisp counterparts in the > meaning of the tests) where
> - eq is true if both arguments have the same value (that is, both are > numerically equal or both are equivalent strings) > - eql is true if both arguments are the same, identical object > - equal does a comparison to test if the two objects are structurally > similar (ie. in the case of a PerlArray, an element-by-element > comparrison would be performed to determine the similarity of the > structure.)
> Cory
I think this is definitely something we should do if we want to confuse people as much as possible :-)
Much can be said about this topic, but let's keep in mind that:
- The length of the opcode name is not important for execution speed or memory space used (this contrary to the early LISP machines/interpreters).
- English is only a small language (with respect to the amount of native speakers, which are mainly restricted to a number of large islands and some of the residents of a large and mostly uninhabited landmass somewhere on the western hemisphere) :-) Non-native speakers can not be trusted to immediately grasp the semantic differences between things as: - equal/identical/same - compare/test
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.
And remember, I am nobody... :-)
++Jos.es
-- Viel mehr als gestern liebe ich dich heute. Doch weniger noch als ich dich morgen lieben wird. "Wie vor Jahr und Tag", Reinhard Mey
> 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 > possible. So no eq/eql/equal, but rather > same_address/same_content/compare/compare_as_num/compare_as_string.
Some of those are probably a little too verbose for my tastes. ;)
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'.
With respects to the compare_as_num/compare_as_string opcodes, there's also already a 'cmp' opcode and there already seems to be the established naming scheme of opcodeX, where X is one of n/i/s/p, depending on the type being dealt with (ie. cleari, clearn, clears, clearp).
> 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'.
Oops, correction there - I'd forgotten an earlier post that pointed out the proposed functionality of eqval/eq_val/eq_value had already been implemented.
Jos Visser <j...@osp.nl> 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, <op>, <op>_num, <op>_string for <op> in (lt le gt ge)
eq and ne are a bit special - yes they do vtable->is_equal now, but that might be wrong when either numerically or string-compare is intended.
<op> and (<op>_num, <op>_string) seem to be suitable for languages that don't have different compare ops and those like perl that have respectively.
> ++Jos.es
leo
[1] eq, ne, lt, le, gt, ge are already widely used
cspen...@sprocket.org (Cory Spencer) wrote in message <news:Pine.LNX.4.58.0311281018050.25627@okcomputer.antiflux.org>... > Well, a page could be stolen from the Lisp book by defining eq/eql/equal > opcodes (though in ths case, differing from the Lisp counterparts in the > meaning of the tests) where
> - eq is true if both arguments have the same value (that is, both are > numerically equal or both are equivalent strings) > - eql is true if both arguments are the same, identical object > - equal does a comparison to test if the two objects are structurally > similar (ie. in the case of a PerlArray, an element-by-element > comparrison would be performed to determine the similarity of the > structure.)
> 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'.
So just to follow up on this thread, was there any preference at all for the name of the opcode performing equality testing of PMC memory addresses? I needed the functionality for the code I'm working on, so I've created a patch implementing an "eq_addr" opcode...
> 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 eq_addr (or whatever it's eventually destined to be named) to test for equality between symbol types. (I'm sure there's another hackish way of implementing the test, but this seemed like the cleanest way of doing it at the time...)
> > 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'.
>So just to follow up on this thread, was there any preference at all for >the name of the opcode performing equality testing of PMC memory >addresses? I needed the functionality for the code I'm working on, so >I've created a patch implementing an "eq_addr" opcode...
Make it eq_addr. We'll go with that scheme for the other comparisons (eq_str, eq_num) as well. -- Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
j...@osp.nl (Jos Visser) wrote in message <news:20031128174129.GD10329@jadzia.josvisser.nl>... > I think this is definitely something we should do if we want to confuse > people as much as possible :-)
Not necessarily. Most programmers have at least some understanding of mathematics in the language in which they are about to use when programming.
Equality, identity, and congruenc[ey] are three mathematical principals which are fairly basic and fairly widely understood even outside the mathematic and computer fields. I don't think that making use of these terms would confuse so many people. I may be wrong.
> 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.
How about eq/ident/congruent? Since this is roughly the order in which they would be used, from most to least, it even maintains Huffman coding for the ops.
