Re: Showing two test failures...

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/src/code/reader.lisp#L268

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