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

Bug #714289 reported by Jean-Philippe Paradis on 2011-02-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
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)

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

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

tags: added: review
Ha-Duong Nguyen (cmpitg) wrote :

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.

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.

Attila Lendvai (attila-lendvai) wrote :

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

the aggregated time spent on hunting bugs is wasted time.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers