[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Atoms in association lists
Received: from LIVE-OAK.LCS.MIT.EDU.ARPA (MIT-LIVE-OAK.DialNet.Symbolics.COM) by GOLD-HILL-ACORN.DialNet.Symbolics.COM via DIAL with SMTP id 74916; 9 Jul 87 09:06:26-EDT
Received: from SAIL.STANFORD.EDU (SAIL.STANFORD.EDU.ARPA) by LIVE-OAK.LCS.MIT.EDU.ARPA via INTERNET with SMTP id 50799; 9 Jul 87 08:06:44-EDT
Received: from [184.108.40.206] by SAIL.STANFORD.EDU with TCP; 9 Jul 87 04:52:04 PDT
Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103750; Thu 9-Jul-87 07:50:39 EDT
Date: Thu, 9 Jul 87 07:49 EDT
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Subject: Re: Atoms in association lists
To: firstname.lastname@example.org, dml@NADC.ARPA
Date: Thu, 9 Jul 87 06:23 EDT
Actually, GCLisp handles atoms in alists by ignoring them,
whether they are strings, NIL, or other symbols. E.g.,
(SETQ abc '(c (c . 3) NIL (NIL . 4)))
(ASSOC 'c abc) --> (c . 3)
(ASSOC nil abc) --> (NIL . 4)
This is in accordance with CLtL, I believe.
Since NIL is a list
But NIL is not a cons. See page 281 of CLtL.
as well as an atom and (car NIL) => NIL
the correct result is
(assoc NIL '((c . 3) NIL (NIL . 4))) => NIL
(NIL . 4) should be returned, as someone stated earlier.
The version of GCLisp I work with (2.4) evaluates it correctly. If an
earlier version does return (NIL . 4) then it is a bug. (I didn't try it
on any earlier versions.)
-- sidney markowitz <email@example.com>
Gold Hill Computers
No Sidney, I believe we are not in conformance with the spec since we fail
the specific test case mentioned in CLtL. This is a long-reported bug for
which the bug form sits on my desk this very instance. It is still a bug
in 2.9.3 (beta release of 3.0).