antik-devel

Download

antik-devel@common-lisp.net

April 2012

2 participants
2 discussions

[Antik-devel] Sharp-m reader macro ignores *read-suppress* (+ patch)
by Martin Schmauder 28 Apr '12

28 Apr '12

Hi, I have encountered a problem with the sharp-m reader macro function. The sharp-m reader macro function (lambda in grid/functions.lisp, l. 202) uses the function cl:read-delimited-list to read the macro arguments. However, when cl:*read-suppress* is true, read-delimited-list always returns nil (See *read-suppress* in CLHS.) That value is then (wrongly) passed to grid:check-initial-contents, which (rightly) signals the error "Initial-contents specified as NIL." The following code can be used to observe the behaviour. No matter what (valid or invalid) code is inside the sharp-m parentheses, the error will be signaled. (let ((*read-suppress* t)) (with-input-from-string (stream "#m(1 2 3)") (read stream))) The solution is to call read-delimited-list and then check if we have to ignore its return value with "(unless *read-suppress* ...)". Patch attached. By the way, how I encountered this issue: When I compile a file with C-c C-k and the compilation yields warnings or notes, the Slime/SBCL combination seems to re-read the file with *read-suppress*. Any sharp-m macro that is then read triggers the error. Try with: #m(1 2 3) (defun foo (bar)) ; unused variable style-warning Comments? Martin

2 1

[Antik-devel] Sharp-m reader macro function ignores *read-suppress* (+ patch)
by Martin Schmauder 25 Apr '12

25 Apr '12

Hi, the sharp-m reader macro function (grid/functions.lisp, l. 202) ignores cl:*read-suppress*. When *read-suppress* is true, the function unconditionally signals the error "Initial-contents specified as NIL." The following code can be used to observe the behaviour. No matter what (valid or invalid) code is inside the sharp-m parentheses, the error will be signaled. (let ((*read-suppress* t)) (with-input-from-string (stream "#m(1 2 3)") (read stream))) I encountered this in Emacs: When I compile a file with C-c C-k and the compilation yields warnings or notes, the Slime/SBCL combination seems to re-read the file with *read-suppress*. Any sharp-m macro that is then read triggers the error. Try with: #m(1 2 3) (defun foo (bar)) ; provoke unused variable style-warning My solution is to put a simple "(unless *read-suppress* ...)" at the appropriate place: if *read-suppress* is true, the macro contents will still be read but then ignored. A patch is attached. The patch did not break any tests for me. Does this seem sane? Comments? Martin

1 0