[Slime-devel] Showing two test failures...
eller.helmut at gmail.com
Mon Aug 25 19:05:30 UTC 2014
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 , at 1 (bar))
> That , at 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))))
>> (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
> It is actually non-portable, the macro character function is provided
> by the implementation through make-dispatch-macro-character:
> 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:
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".
More information about the slime-devel