Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal to remove the dependency on cl-annot #63

Open
vindarel opened this issue Oct 14, 2020 · 6 comments
Open

Proposal to remove the dependency on cl-annot #63

vindarel opened this issue Oct 14, 2020 · 6 comments

Comments

@vindarel
Copy link

Hello,

I see that cl-annot is only used for the @doc annotation, for the usual defmacro, defgeneric and defvar forms, which all accept a docstring.

This prevents me from quickloading Jonathan in a project that uses pythonic-string-reader.

If there is no good reason to keep cl-annot, I'd like to remove them. Shall I?

Best,

@svetlyak40wt
Copy link
Contributor

Byt the way, also seems annotations breaks code navigation. When I press v on the first stackframe:

Unexpected EOF found:
{"foo": 123.5.6}
   [Condition of type JONATHAN.ERROR:<JONATHAN-UNEXPECTED-EOF-ERROR>]

Restarts:
 0: [RETRY] Retry SLY mREPL evaluation request.
 1: [*ABORT] Return to SLY's top level.
 2: [ABORT] abort thread (#<THREAD "sly-channel-1-mrepl-remote-1" RUNNING {1002CB0503}>)

Backtrace:
 0: ((LABELS JONATHAN.DECODE::DISPATCH :IN JONATHAN.DECODE:PARSE) #<unavailable argument> #<unavailable argument>)
 1: (JONATHAN.DECODE:PARSE #<unavailable argument> :AS #<unavailable argument> :JUNK-ALLOWED #<unavailable argument> :KEYWORDS-TO-READ #<unavailable argument> :KEYWORD-NORMALIZER #<unavailable argument> :..
 2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (JONATHAN.DECODE:PARSE "{\"foo\": 123.5.6}") #<NULL-LEXENV>)
 3: (EVAL (JONATHAN.DECODE:PARSE "{\"foo\": 123.5.6}"))

SLY opens this form:

@doc
"LISP value of {}."
(defvar *empty-object-value* nil)

@vindarel
Copy link
Author

vindarel commented Mar 8, 2021

I had a try here: ciel-lang@f7c971f

cl-annot is still required for progn-form-last and progn-form-replace-last (but without the reader syntax).

I stopped because of the use of cl-annot-prove in circle.yaml

    - run-annot-prove -p *-test.asd

(although it is actually not used in tests ?)

@svetlyak40wt
Copy link
Contributor

BTW, @vindarel seem the problem you have is caused by inproper use of read table. Each package should use named-readtables to prevent such conflicts.

@vindarel
Copy link
Author

mmh. pythonic-string-reader uses named-readtables. In my stacktrace I see a call to (CL-SYNTAX::%USE-SYNTAX (:CL-ANNOT)) which wants to (merge-readtables-into *readtable* syntax) ). I wonder if this expected behavior from cl-syntax, because here I didn't ask to use both syntaxes at the same time. cl-annot is used internally only to Jonathan.

@svetlyak40wt
Copy link
Contributor

I see, cl-syntax copies the readtable before changing it:

(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*)))

Don't understand what problem do you have.

It would be nice if you create a minimal example to reproduce the problem.

@vindarel
Copy link
Author

Sure, here it is: smithzvk/pythonic-string-reader#3 if not the correct place, it should be a better place than jonathan's issue tracker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants