[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bugs found in MCL 2.0b1p2
- To: meehan@Pa.dec.com
- Subject: Re: Bugs found in MCL 2.0b1p2
- From: george@hsvaic.boeing.com (George Williams)
- Date: Tue, 4 Jun 91 06:58:29 CDT
- Cc: bug-mcl@cambridge.apple.com, info-mcl@cambridge.apple.com
> From: meehan@Pa.dec.com (Jim Meehan)
> Date: Mon, 3 Jun 91 13:16:56 PDT
[...]
> I believe you're assuming a closer connection between defconstant and
> eq than the language actually defines. (defconstant *xxx* '(nil))
> indicates that the BINDING of the value '(nil) to the variable *xxx*
> will not change, e.g., the value is a cons. Inserting a constant into
> a list doesn't imply that you can match it later with eq.
Isn't the value of *xxx* equal to the specific "(nil)" that was
specified in the defconstant? The value that was inserted into the
list was the value of *xxx*, not just any "(nil)".
> (defconstant *xxx* '*xxx*) will "work" because interned symbols are
> guaranteed to be EQ, at least until there's some other reference to
> that symbol.
Are you saying that this will quit working because another reference
gets made to the symbol?
> For "anonymous" marking-values that can't collide with any other values,
> I recommend
> (defvar *xxx* (gensym))
That sound's like a good idea. But why won't defconstant work with
this one?
> or
> (defvar *xxx* (cons nil nil))
> Note: defvar and not defconstant. What's important is that there's
> a unique VALUE being used. The constancy of the BINDING is irrelevant.
[Actually, defparameter would be more appropriate, but CLtL2 is not
definitive on this.]
On defconstant, CLtL2 says (p87) "the compiler must take care that
"copies" appear to be eql to the object that is the actual value of
the constant. For example, the compiler may freely make copies of
numbers but must exercise care when the value is a list." And on eql
(p105) "The eql predicate is true if its arguments are eq, or if they
are numbers of the same type with the same value, or if they are
character objects that represent the same character."
> Footnote: You say that eq failed "after some processing". I'd be
> very surprised to hear that it succeeded at one time and failed later
> on. If that actually happened, it does indeed sound like a bug.
This is someone else's code, so it's been difficult for me to find
exactly where the list is being first created and test it there.
However, I have tested similar cases, even calling the same function
which creates the list structure I mentioned, and they have always
been eq.
Hope I'm not sounding defensive. I'm just trying to understand.
George Williams
Boeing Computer Services Internet: george@hsvaic.boeing.com
POBox 240002, M/S JY-58 UUCP: ...!uw-beaver!bcsaic!hsvaic!george
Huntsville AL 35824-6402 Phone: 205+464-4968 FAX: 205+464-4930