[comp.sys.handhelds] SAME

bson@rice-chex.ai.mit.edu (Jan Brittenson) (06/29/91)

In a posting of [29 Jun 91 07:59:30 GMT]
   stevev@greylady.uoregon.edu (Steve VanDevender) writes:

 > Despite what the Programmer's Reference Manual or the Owner's Manual
 > volume II, p. 492 says basically the same thing you cited), it is
 > clear that SAME compares the binary representations of binary integers
 > and not just their values.

   Indeed. SAME basically just dispatches to the prefixed machine code
at 3b97. The routine at 3b97 checks, in order:

	1. that the object type is identical, and

	2. that the object sizes are identical, and

	3. that the binary representation is identical

If any test fails, the objects are not considered the same.

---

Some general observations...

   SAME is preferable over == in cases where no argument evaluation is
desired. Which makes a comparison to LISP's EQ somewhat convoluted,
because the latter always evaluates its arguments and compares the
results (if the LISP in question even supports NLAMBDAs or macros or
some other means of inhibiting argument evaluation).

SAME is useful when working with algebraics:

	'A' 'A' SAME		@ True
	'A' 'B' SAME		@ False
	'X+1' '1+X' SAME	@ False

   So, why doesn't == always evaluate its arguments? It evaluates all
arguments except programs, which are compared using SAME. I find this
inconsistent. (Strings and library data, yes, but programs?!) And
shouldn't the array [ (1,0) ] be == to the array [ 1 ] given that
(1,0) == 1? Peculiar.

						-- Jan Brittenson
						   bson@ai.mit.edu