new compiler error re: SET-DISPATCH-MACRO-CHARACTER

[Faré]

I just tried compiling puri with asdf 3.3.0, using either quicklisp or
the latest commit (b537e93 from August 29 2015) on sbcl 1.3.20, and
had no issue whatsoever.

Odds are the problem is on your side, probably with your using
with-standard-io-syntax or some such. Note that it is very rude to use
set-dispatch-macro-character on a readtable you didn't specifically
setup, especially since it might be a read-only readtable, or worse, a
writable one used by people who assume it won't be modified.

I've had a branch of ASDF, called "syntax-control", supposed to bring
*some* sanity in readtables used while building with ASDF. It has
bitrotten in the last 4 years and is nowhere near being merged at this
point.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Opportunity is missed by most people because it comes dressed in overalls
and looks like work.    — T. A. Edison


On Wed, Oct 11, 2017 at 8:41 PM, Konstanski, Carlos
<carlos.konstanski at verizonwireless.com> wrote:
> This is a bug report. I'm using puri as an example, but it's not a puri
> bug.
>
> With the latest version of asdf (3.3.0) puri no longer compiles. The
> following compiler error is thrown:
>
>    SET-DISPATCH-MACRO-CHARACTER would modify the standard readtable.
>    [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR]
>
> In:
>
>   0: (SET-DISPATCH-MACRO-CHARACTER #\# #\u #<FUNCTION PURI::SHARP-U>
> #<READTABLE {100002D6C3}>)
>
> The code:
>
> (defun sharp-u (stream chr arg)
>   (declare (ignore chr arg))
>   (let ((arg (read stream nil nil t)))
>     (if *read-suppress*
>         nil
>       (if* (stringp arg)
>          then (parse-uri arg)
>          else
>          (internal-reader-error
>           stream
>           "#u takes a string or list argument: ~s" arg)))))
>
> (set-dispatch-macro-character #\# #\u #'puri::sharp-u)
>
> What puri is doing re: SET-DISPATCH-MACRO-CHARACTER is totally by the
> book. Why is this suddenly an error? Is there a workaround?
>
> Backing up to the next most recent release of asdf makes the problem go
> away:
>
> dev-lisp/asdf-3.2.1-r1:0/3.2.1-r1
> dev-lisp/uiop-3.2.1:0
>
> I tried to find the asdf changelog to see if this is a documented
> change. But the link is broken.
> https://common-lisp.net/project/asdf/Changelog
>
> uiop seems to be closely tied to asdf. Not sure which package is
> actually at fault.
> --
> Carlos Konstanski
>