SBCL

SYMBOL-MACROLET behaves incorrectly in the presence of duplicate binding names

Bug #714289 reported by Jean-Philippe Paradis on 2011-02-06

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	SBCL	Triaged	Low	Unassigned

Bug Description

What I do:
(symbol-macrolet ((test 0)
(test 1))
test)

What happens:
SBCL signals "STYLE-WARNING: duplicate definitions in ((TEST 0) (TEST 1))"
and returns 0.

What I expected to happen:
We argued a bit on #lisp about possible/correct semantics for such a form. But it's clear that the current behavior is unacceptable because nobody would expect or rely on such behavior.

The conservative thing to do would simply be to signal an error.

SBCL version: 1.0.42
uname -a: Linux dynamorph 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux

*features*:
(:SWANK :QUICKLISP :SB-BSD-SOCKETS-ADDRINFO :ASDF2 :ASDF :ANSI-CL :COMMON-LISP
:SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL
:SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :UNIX :ELF :LINUX :SB-THREAD
:LARGEFILE :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK
:COMPARE-AND-SWAP-VOPS :UNWIND-TO-FRAME-AND-CALL-VOP :RAW-INSTANCE-INIT-VOPS
:STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-VECTORS
:STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-FIXED-OBJECTS :ALIEN-CALLBACKS
:CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-BARRIER-VOPS :LINKAGE-TABLE
:OS-PROVIDES-DLOPEN :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T)

Tags:

Nikodemus Siivola (nikodemus) on 2011-02-16

Changed in sbcl:
importance:	Undecided → Low
status:	New → Triaged
tags:	added: easy

Revision history for this message

Roman Marynchak (roman-marynchak) wrote on 2011-03-25:

0001-Signal-error-when-SYMBOL-MACROLET-bindings-contain-d.patch Edit (1.7 KiB, text/plain)

The simple warning -> error replacement seems to work just fine.

tags:

added: review

Revision history for this message

Ha-Duong Nguyen (cmpitg) wrote on 2011-03-26:

I don't think that's an expected behaviour. HyperSpec does not say anything about binding duplicate name in SYMBOL-MACROLET form. The default behaviour of some other Common Lisp implementations (CCL, ECL, ABCL) is letting it be, though the results are inconsistent among them.

Revision history for this message

Roman Marynchak (roman-marynchak) wrote on 2011-03-26:

Well, I don't think that many people will deliberately bind the same symbol twice, and this error is not likely to break the legacy code compilation. In case you look at the language in general, most cases of duplicate bindings are errors (in LET, in LOOP etc.). So I support the idea to make this case an error too, though it is still disputable.

Revision history for this message

Attila Lendvai (attila-lendvai) wrote on 2011-03-26:

legacy code can be fixed, or run with an old SBCL.

the aggregated time spent on hunting bugs is wasted time.