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

parseedn-print tag readers #6

Open
nivekuil opened this issue Jun 6, 2020 · 3 comments
Open

parseedn-print tag readers #6

nivekuil opened this issue Jun 6, 2020 · 3 comments

Comments

@nivekuil
Copy link

nivekuil commented Jun 6, 2020

For parseedn-read, we can pass an alist of readers to convert e.g. #uuid into a string.
Could this be done in the inverse operation, parseedn-print, as well?
Currently I've just patched it like so:

   ((consp datum)
    (cond
     ((not (listp (cdr datum))) ; dotted pair
      (error "Don't know how to print: %s" datum))
     ((eq 'edn-set (car datum))
      (insert "#{") (parseedn-print-seq (cadr datum)) (insert "}"))
+     ((eq 'edn-uuid (car datum))
+      (insert "#uuid ") (parseedn-print-seq (cdr datum)))
     (t (insert "(") (parseedn-print-seq datum) (insert ")"))))
@bbatsov
Copy link
Member

bbatsov commented Jun 6, 2020

The suggestion seems reasonable to me. Let's see what @plexus thinks about it as well.

@plexus
Copy link
Contributor

plexus commented Jun 6, 2020

I think the reason we don't have custom print handlers is that elisp doesn't really have custom types. Even the common lisp style types are really just cons cells IIRC so it's hard to distinguish. But if we can offer custom print handlers in a way that makes sense then I'm all for it.

@plexus
Copy link
Contributor

plexus commented Sep 9, 2020

Having another look at this, I think it would be fair to provide an optional second argument to parseedn-print and parseedn-print-str which is an a-list from symbol to printing function, where we dispatch on the first item in a list if it is a symbol. This would only cover the case where "custom" types are represented as a cons with a symbol "tag", but this is the most common way to do so in Elisp and it's what cl-struct does (if I'm not mistaken).

A PR for that would be very welcome.

However for the issue that @nivekuil raised I think the actual problem is that while we parse inst and uuid (since they are part of the EDN spec) we don't print them correctly. I added printing for #inst and #uuid in #7 .

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

3 participants