[Openmcl-devel] Side effects when redefining dispatching reader macro?

[Mirko Vukovic]

On Fri, Nov 13, 2015 at 4:25 AM, Ron Garret <ron at flownet.com> wrote:

>
> On Nov 12, 2015, at 2:27 PM, Gary Byers <gb at clozure.com> wrote:
>
> On 11/12/2015 11:37 AM, Ron Garret wrote:
>
> (MAKE-DISPATCH-MACRO-CHARACTER #\# NIL **readtable**)
>
> CLHS says (of MAKE-DISPATCH-MACRO-CHARACTER) that,
>
> "Initially, every *character*
> <http://www.lispworks.com/documentation/lw50/CLHS/Body/26_glo_c.htm#character>
> in the dispatch table associated with the *char* has an associated
> function that signals an error of *type*
> <http://www.lispworks.com/documentation/lw50/CLHS/Body/26_glo_t.htm#type>
> *reader-error*
> <http://www.lispworks.com/documentation/lw50/CLHS/Body/e_rder_e.htm#reader-error>
> ."
>
> In the body of your message, you seemed to expect #' to have retained its
> original definition.
>
> If the term "... makes char be a dispatching-macro-character ..." is read
> as "does nothing if the character is already defined as a
> dispatching-macro, else ...",
> your expectation is reasonable. I am probably more accustomed to the
> behavior that that you said that you get in 1.10, but both expectations
> seem reasonable.
>
> Portable code could avoid the issue by calling
> GET-DISPATCH-MACRO-CHARACTER and only calling MAKE-DISPATCH-MACRO-CHARACTER
> if the character is not already defined as a dispatching macro.  I don't
> know what the library that the original poster mentioned does. or what
> version of that library they are using.
>
>
> That’s reasonable.  My point was mainly that this has nothing to do with
> named readtables.  It might not even be a bug at all.  One could argue that
> the OP should simply elide the (:macro-char #\# :dispatch) clause from his
> code.
>
> rg
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>
> OP here:

My original example was copied from the Antik library.  It was preventing
the library from loading.  I then compared it with SBCL (both latest CCL
and SBCL Windows version).

Eliding the macro-char definition is the way to go

Mirko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20151113/3dc14c9c/attachment.htm>