1) The HS says that
(eq (cons 'a 'b) (cons 'a 'b))
always returns false but
(eq '(a . b) '(a . b))
might be true. Why is this ?
2) Under what (realistic) circumstances might
(eq 1 1) be false ?
On Mar 31, 8:49 am, Spiros Bousbouras <······@gmail.com> wrote:
> 1) The HS says that
> (eq (cons 'a 'b) (cons 'a 'b))
> always returns false but
> (eq '(a . b) '(a . b))
> might be true. Why is this ?
Because the compiler is allowed to select a canonical instance for
quoted constants (since you're not supposed to modify them). So, the
compiler could use the same cons for both occurrences of the quoted
dotted pair.
> 2) Under what (realistic) circumstances might
> (eq 1 1) be false ?
Realistically, none, but use `eql' anyway.
-- Scott
Scott Burson <········@gmail.com> writes:
> On Mar 31, 8:49 am, Spiros Bousbouras <······@gmail.com> wrote:
>> 1) The HS says that
>> (eq (cons 'a 'b) (cons 'a 'b))
>> always returns false but
>> (eq '(a . b) '(a . b))
>> might be true. Why is this ?
>
> Because the compiler is allowed to select a canonical instance for
> quoted constants (since you're not supposed to modify them). So, the
> compiler could use the same cons for both occurrences of the quoted
> dotted pair.
Explicitly, you can implement ' reader macro as:
(set-macro-character #\'
(let ((literal-stuff (make-hash-table :test (function equal))))
(lambda (stream quote)
(declare (ignore quote))
(let ((new-literal (read stream nil t)))
(or (gethash new-literal literal-stuff)
(setf (gethash new-literal literal-stuff) new-literal)))))
nil *readtable*)
>> 2) Under what (realistic) circumstances might
>> (eq 1 1) be false ?
For example, imagine you're implementing CL over perl. I mean,
perhaps you have to write perl script, but you just cannot stand perl
syntax, so you decide to implement a CL over perl to be able to
produce perl scripts... Ok then, in perl data is not typed. 1 ==
"1". When you have 1 in perl you cannot tell if it's a string, an
integer, a float or what. So you implement all lisp objects as a perl
hash, with a type slot and a value slot. When you write (eq 1 1),
it's translated to:
lisp_eq({type=>integer,value=>1},{type=>integer,value=>1});
and of course, the two hash tables are not 'eq'.
Otherwise, very few are the cl implementations that have not (eq 1 1),
but most of them have (not (eq (1+ most-positive-fixnum)
(1+ most-positive-fixnum))).
> Realistically, none, but use `eql' anyway.
>
> -- Scott
--
__Pascal Bourguignon__ http://www.informatimago.com/
"What is this talk of "release"? Klingons do not make software
"releases". Our software "escapes" leaving a bloody trail of
designers and quality assurance people in its wake."
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Scott Burson <········@gmail.com> writes:
>
> > On Mar 31, 8:49 am, Spiros Bousbouras <······@gmail.com> wrote:
> >> 1) The HS says that
> >> (eq (cons 'a 'b) (cons 'a 'b))
> >> always returns false but
> >> (eq '(a . b) '(a . b))
> >> might be true. Why is this ?
> >
> > Because the compiler is allowed to select a canonical instance for
> > quoted constants (since you're not supposed to modify them). So, the
> > compiler could use the same cons for both occurrences of the quoted
> > dotted pair.
>
> Explicitly, you can implement ' reader macro as:
>
> (set-macro-character #\'
> (let ((literal-stuff (make-hash-table :test (function equal))))
> (lambda (stream quote)
> (declare (ignore quote))
> (let ((new-literal (read stream nil t)))
> (or (gethash new-literal literal-stuff)
> (setf (gethash new-literal literal-stuff) new-literal)))))
> nil *readtable*)
I don't think so. The compiler is allowed to coalesce similar
constants, but the reader is not. The reader can be used to read things
that won't necessarily be evaluated.
Also, your above implementation doesn't translate '<expression> to
(QUOTE <expression>), it translates it to <expression>, so it doesn't
actually quote anything.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> Scott Burson <········@gmail.com> writes:
>>
>> > On Mar 31, 8:49 am, Spiros Bousbouras <······@gmail.com> wrote:
>> >> 1) The HS says that
>> >> (eq (cons 'a 'b) (cons 'a 'b))
>> >> always returns false but
>> >> (eq '(a . b) '(a . b))
>> >> might be true. Why is this ?
>> >
>> > Because the compiler is allowed to select a canonical instance for
>> > quoted constants (since you're not supposed to modify them). So, the
>> > compiler could use the same cons for both occurrences of the quoted
>> > dotted pair.
>>
>> Explicitly, you can implement ' reader macro as:
>>
>> (set-macro-character #\'
>> (let ((literal-stuff (make-hash-table :test (function equal))))
>> (lambda (stream quote)
>> (declare (ignore quote))
>> (let ((new-literal (read stream nil t)))
>> (or (gethash new-literal literal-stuff)
>> (setf (gethash new-literal literal-stuff) new-literal)))))
>> nil *readtable*)
>
> I don't think so. The compiler is allowed to coalesce similar
> constants, but the reader is not. The reader can be used to read things
> that won't necessarily be evaluated.
>
> Also, your above implementation doesn't translate '<expression> to
> (QUOTE <expression>), it translates it to <expression>, so it doesn't
> actually quote anything.
Yep, sorry, I missed a `(quote ,...).
Note that the reader already coalesces some objects: the interned symbols.
Are you sure it is not allowed to coalesce other objects?
--
__Pascal Bourguignon__
Pascal J. Bourguignon writes:
> Barry Margolin writes:
> > The compiler is allowed to coalesce similar constants, but the
> > reader is not.
> Note that the reader already coalesces some objects: the interned
> symbols. Are you sure it is not allowed to coalesce other objects?
QUOTE just returns the quoted object:
http://clhs.lisp.se/Body/s_quote.htm
There's nothing about EQUAL in there.
Maybe you remember previous discussions about backquote? I believe
coalescing would be permitted, as long as the returned object is EQUAL
to what the backquote expression would return:
http://clhs.lisp.se/Body/02_df.htm
In article <··············@pbourguignon.anevia.com>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Note that the reader already coalesces some objects: the interned symbols.
It's specifically REQUIRED to do that.
> Are you sure it is not allowed to coalesce other objects?
If it could, there wouldn't have been any need to give this permission
to the compiler.
The thing is, coalescing is only allowed for *constants*. Something
isn't a constant until it's being used as part of a program. When
calling READ, it's just data.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Spiros Bousbouras wrote:
> 1) The HS says that
> (eq (cons 'a 'b) (cons 'a 'b))
> always returns false but
> (eq '(a . b) '(a . b))
> might be true. Why is this ?
Because '(a . b) is a literal object (and should not be modified), a
compiler might make both references of them point to the same cons.
> 2) Under what (realistic) circumstances might
> (eq 1 1) be false ?
An implementation could create two different 1 objects. According to
Cliki at least, in ABCL EQL fixnums are not EQ. (I'm having trouble
duplicating that though).
Brian <··············@gmail.com> wrote:
+---------------
| Spiros Bousbouras wrote:
| > 2) Under what (realistic) circumstances might
| > (eq 1 1) be false ?
| An implementation could create two different 1 objects. According to
| Cliki at least, in ABCL EQL fixnums are not EQ. (I'm having trouble
| duplicating that though).
+---------------
Try using larger fixnums. Some implementations of Lisp/Scheme
"intern" a few fixnums close to zero [to avoid excess consing
of small temps in loops], but cons up all others. A notable example
of this was SIOD Scheme, which typically "interned" the integers
0-255 [in one version] or 0-2047 [in another], but provided a
command-line option ("-n") to adjust this:
$ siod -n2048
...[chatter]...
> (eq? 1 1)
t
> (eq? 2047 2047)
t
> (eq? 2048 2048)
()
> (eq? 12345 12345)
()
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
P� Mon, 31 Mar 2008 17:49:09 +0200, skrev Spiros Bousbouras
<······@gmail.com>:
> 2) Under what (realistic) circumstances might
> (eq 1 1) be false ?
try (eq (1+ most-positive-fixnum) (1+ most-positive-fixnum))..
This doesn't 'fit' into a cons cell so you get the place of a bignum
instead.
So using eq to compare values is asking for trouble.
--------------
John Thingstad