On 8/28/06, Barton Willis <willisb at unk.edu> wrote:
> I just changed meqp. Now when an argument to meqp
> has both the array property and the value property,
> meqp compares the scalar values:
>
> (%i2) q[1]:r[1]:1$
> (%i3) is(equal(q,r));
> (%o3) true <-- because the arrays are equal
>
> (%i4) is(equal('q,'r));
> (%o4) true
>
> Let's give 'q' a value. Now meqpp checks the scalar values
> of q and r
>
> (%i5) q : 42$
> (%i7) is(equal('q,'r)), prederror : false;
> (%o7) unknown
I think it's rather confusing to have the meaning of is(equal(q,r))
where q and r are arrays change if you assign a value to q or r.
I'm all for making arrays into first-class objects, so you can assign
them (using q:r or maybe something like q[]:r[]) and otherwise
manipulate them, but until we do that, I don't think 'is' is the place
to innovate in that direction.
By the way, if lambda([x],x)==lambda([y],y), shouldn't it also be true that
f(x):=x$
g:'f$
is(equal(f,lambda([x],x))) => true
is(equal(identity,lambda([x],23,x)) => true
(the 23 has no effect on the meaning of the function...)
is(equal(f,g)) => true
( f(x) has the same value as g(x) )
These are all extensionally identical....
Now, let's see, how many meanings might 'f' have: a scalar, an array,
and a function. Oh, and the name of a function... or an array.
Do we really want 'is' to try to figure out what the user meant? Or
should we keep it simple and clear?
-s