Hi!
Just now playing a little with ABCL(1.3.2), I saw some strange behaviour:
CL-USER> '(2 . 5) (2 . 5) CL-USER> '(2 . 5 . 5) (2 . 5) CL-USER> (equal '(2 . 5) '(2 . 5 . 5)) T
while other implementations give me an error when i type '(2 . 5 . 5) it's a bug or ANSI CL allows this?
greetings,
Alejandro
-- Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas
Infomed: http://www.sld.cu/
On 24 Jul 2015, at 14:33, Alejandro Zamora Fonseca <terefv@ltu.sld.cu mailto:terefv@ltu.sld.cu> wrote:
Hi!
Just now playing a little with ABCL(1.3.2), I saw some strange behaviour:
CL-USER> '(2 . 5) (2 . 5) CL-USER> '(2 . 5 . 5) (2 . 5) CL-USER> (equal '(2 . 5) '(2 . 5 . 5)) T
while other implementations give me an error when i type '(2 . 5 . 5) it's a bug or ANSI CL allows this?
Depends.
ANSI CL specifies the lisp reader in such a way that (2 . 5 . 5) is not a valid syntax. However, ANSI CL specifies that implementation may extend the CL language, UNDER THE CONDITION that extensions BE DOCUMENTED.
Therefore, IF it is written in ABCL documentation that (2 . 5 . x) reads as (2 . 5) THEN it is not a bug, but an ABCL specific extension, ELSE it is a conformity bug, it should signal a READER-ERROR (or perhaps just an ERROR).
Notice that since this is an extensions on the reader macro character #(, it could be expected that the standard reader macro character for #( still exist in the system and be obtained by (copy-readtable NIL) which shall return the standard readtable. For example, in ccl the default *readtable* is poluted by a lot of extensions such as the dispatching #/ #_ #$ macro characters, but you can throw them away with (setf *readtable* (copy-readtable NIL)). One could expect the same here.
http://www.lispworks.com/documentation/HyperSpec/Body/02_da.htm http://www.lispworks.com/documentation/HyperSpec/Body/02_da.htm http://www.lispworks.com/documentation/HyperSpec/Body/01_f.htm http://www.lispworks.com/documentation/HyperSpec/Body/01_f.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_cp_rdt.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_cp_rdt.htm
On 2015/7/26 12:30, Pascal J. Bourguignon wrote:
On 24 Jul 2015, at 14:33, Alejandro Zamora Fonseca <terefv@ltu.sld.cu mailto:terefv@ltu.sld.cu> wrote:
Hi!
Just now playing a little with ABCL(1.3.2), I saw some strange behaviour:
CL-USER> '(2 . 5) (2 . 5) CL-USER> '(2 . 5 . 5) (2 . 5) CL-USER> (equal '(2 . 5) '(2 . 5 . 5)) T
while other implementations give me an error when i type '(2 . 5 . 5) it's a bug or ANSI CL allows this?
Depends.
ANSI CL specifies the lisp reader in such a way that (2 . 5 . 5) is not a valid syntax. However, ANSI CL specifies that implementation may extend the CL language, UNDER THE CONDITION that extensions BE DOCUMENTED.
Therefore, IF it is written in ABCL documentation that (2 . 5 . x) reads as (2 . 5) THEN it is not a bug, but an ABCL specific extension, ELSE it is a conformity bug, it should signal a READER-ERROR (or perhaps just an ERROR).
As far as I can tell, we never intended to extend the reader to accept such forms, so we'll call this a [bug][395].
If changing this to an error breaks anyone's existing code, please let us know.
[395]: [http://abcl.org/trac/ticket/395
armedbear-devel@common-lisp.net