On Mon, Aug 25 2014, Paulo Madeira wrote:
2014-08-25 8:38 GMT+01:00 Helmut Eller:
compile-defun-4 fails due to the "improved" backquote stuff. I haven't followed the discussion. Why is it neccesary to that ,X returns a struct instead of somehing more traditionanal like (unquote X)?
As I see it, that's a correct reader error, you shouldn't be able to
`(list 1 ,1 ,@1 (bar))
That ,@1 cause the equivalent append to fail:
(append (list `1) (list 1) 1 (list `(bar)))
Although I'm not sure I'm looking at the right point of failure, and I didn't actually test it.
The example was:
(defun foo () (list `(1 ,(random 10) 2 ,@(random 3) 3 ,(bar))))
and BAR is an undefined function. There used to one warning but now there are two. If we change it to
(defun foo () (list `(1 ,(random 10) 2 ,@(make-list 3) 3 ,(bar))))
we get back to a single warning and the real issue: previously the source path of the error was (0 3 1 4 2 2) i.e at (bar) but with the new backquote the source path is (0 3 1) which is at `(1 ...). Clearly a less precise location.
The reason I'm asking why this struct was necessary is because sb-c::sub-find-source-paths doesn't descent into that sb-impl::comma struct and the compiler has only sees use the next best path.
I guess sb-c::sub-find-source-paths should be updated or just use lists instead of structs.
find-definition.2-1 fails because a change to set-macro-character. This code used to work:
(let* ((rt (copy-readtable nil))) (flet ((wrap (fun) (lambda (&rest args) (apply args fun)))) (list (assert (get-dispatch-macro-character ## #. rt)) (multiple-value-bind (fun nt) (get-macro-character ## rt) (set-macro-character ## (wrap fun) nt rt)) (assert (get-dispatch-macro-character ## #. rt)))))
but no longer does. Does somebody know if this code is actually non-portable?
It is actually non-portable, the macro character function is provided by the implementation through make-dispatch-macro-character:
http://www.lispworks.com/documentation/HyperSpec/Body/02_add.htm
The dispatch character table may be attached to the macro character function, e.g. a funcallable-standard-object with a slot containing the table. Hence the need for make-dispatch-macro-character. In the case of SBCL, it's a bit more twisted, it actually checks for the closure's value:
https://github.com/sbcl/sbcl/blob/82e75708c947be3ae4e7884241526ba9c81840f6/s...
Surely there are other ways to store dispatch character tables. E.g. the readtable could have a hashtable of dispatch character tables.
I don't see any other portable way make this test pass than with get-macro-character/set-macro-character. So I probably mark this test as "fails for SBCL".
Helmut