3

I like pythonic-string-reader to enable python-esque triple quotes:

(defun hello ()
  """docstring"""
  :hello)

Use it:

(ql:quickload "pythonic-string-reader")
(pythonic-string-reader:enable-pythonic-string-syntax)

it also works with

(named-readtables:in-readtable pythonic-string-reader:pythonic-string-syntax)

But then I want to load the Jonathan library and I get a conflict:

(ql:quickload "jonathan")
=>
Reader macro conflict while trying to merge the macro character
#\" from #<NAMED-READTABLE CL-ANNOT::SYNTAX {1001CC18C3}> into
#<NAMED-READTABLE :CURRENT {1009474833}>.
   [Condition of type EDITOR-HINTS.NAMED-READTABLES:READER-MACRO-CONFLICT]


Backtrace:
  0: (EDITOR-HINTS.NAMED-READTABLES:MERGE-READTABLES-INTO #<NAMED-READTABLE :CURRENT {1009474833}> #<NAMED-READTABLE CL-ANNOT::SYNTAX {1001CC18C3}>)
      Locals:
        CHAR = #\"
        DISP? = NIL
        FROM = #<NAMED-READTABLE CL-ANNOT::SYNTAX {1001CC18C3}>
        NAMED-READTABLES = (#<NAMED-READTABLE CL-ANNOT::SYNTAX {1001CC18C3}>)
        READER-FN = #<FUNCTION SB-IMPL::READ-STRING>
        RESULT-READTABLE = #<NAMED-READTABLE :CURRENT {1009474833}>
        RESULT-TABLE = #<NAMED-READTABLE :CURRENT {1009474833}>
        TABLE = NIL
  1: (CL-SYNTAX::%USE-SYNTAX (:CL-ANNOT))
      Locals:
        NAMES = (:CL-ANNOT)

It isn't right, because I am not asking to use another readtable. Jonathan only uses cl-annot internally.

Who's bug is it (cl-syntax?) and how to solve it?


It works to load Jonathan first and then to enable the pythonic string syntax. However it isn't an acceptable work-around (I want to define a user package with the syntax enabled where the user could load any other library).


Looking at the cl-syntax line error it wants to merge readtables (merge-readtables-into *readtable* syntax) ), at the same time it seems to correctly use copy-readtable:

(defun %use-syntax (names)
  (declare (type (or syntax-designator
                     (proper-list syntax-designator))
                 names))
  (unless (listp names)
    (setq names (list names)))
  (setq *readtable* (copy-readtable))
  (loop for name in names
        for syntax = (find-syntax name)
        for options = (get-options name)
        if (assoc :fuze (if (consp (car options)) options (cdr options))) do
          (handler-bind ((named-readtables:reader-macro-conflict
                            (lambda (_) (declare (ignore _))
                              (invoke-restart 'continue))))
             (merge-readtables-into *readtable* syntax) )
        else do
          (merge-readtables-into *readtable* syntax) )
  (when (find-package :swank)
    (named-readtables::%frob-swank-readtable-alist *package* *readtable*)))

Any ideas? Thanks.

Ehvince
  • 17,274
  • 7
  • 58
  • 79

1 Answers1

3

Evaluating

(cl-syntax::get-options :CL-ANNOT)

Gives

((:MERGE :STANDARD)
 (:MACRO-CHAR #\@ #'CL-ANNOT.SYNTAX:ANNOTATION-SYNTAX-READER))

It looks like the syntax is supposed to merge the :standard readtable, not the curent one. I suspect (copy-readtable nil) would be the better choice here in the function you described.

coredump
  • 37,664
  • 5
  • 43
  • 77
  • `copy-readtable nil` allows me to further load jonathan. I'll reach cl-syntax's issue tracker. (and will likely accept this answer) – Ehvince Mar 10 '21 at 18:04
  • Problem: cl-syntax's repository is archived (https://github.com/m2ym/cl-syntax). A candidate for sharplispers? – Ehvince Mar 10 '21 at 18:08
  • @Ehvince probably, yes, I don't know much how sharplispers is organized – coredump Mar 10 '21 at 18:12
  • 2
    I contacted a member. – Ehvince Mar 10 '21 at 18:22
  • Use named-readtables instead of cl-syntax. :-) – Luís Oliveira Mar 10 '21 at 22:35
  • Anything that unilaterally sets `*readtable*` to the standard readtable is not going to fix the problem. –  Mar 11 '21 at 07:30
  • 1
    @tfb cl-annot is not being very composable by being an extension of the standard readtable, but at least the implementation should honor that. Also, merging with the current readrtable is something that can only lead to conflicts which can only be resolved by the developer using different syntax extensions. I think named-readtables is good at it but I'm interested in knowing about better solutions – coredump Mar 11 '21 at 08:47
  • @coredump: that's not the problem I meant. If the current readtable isn't equivalent to the standard one, then loading a system which replaces it by (a modified copy of) the standard one, making no attempt to merge changes from the current readtable, will lose any changes in the current readtable. So in this case, if the pythonic string syntax is enabled at the point `jonathan` is loaded, it won't be after it's loaded. Which kind of defeats the object of enabling it first. –  Mar 11 '21 at 13:28
  • 1
    @tfb I tested by loading and installing SERIES which adds the #Z reader, then forced the recompilation of jonathan (no conflict here), and the readtable was still the same after compiling and loading it, and the at-doc syntax was not supported. I think this works because the readtable is rebound to itself during compile-file and load, allowing the change to be only visible for the jonathan source files (?) – coredump Mar 11 '21 at 13:50
  • 1
    @coredump: Oh, yes, you're right. Unilaterally setting the readtable will work. Sorry, I was wrong (even more annoyingly I had also tested things but botched my test, by assuming that something was doing `(with-standard-io-syntax ...)`). –  Mar 11 '21 at 14:20