ClojureScript

Support for runtime reading of tagged elements

Details

  • Type: Enhancement Enhancement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Patch:
    Code and Test

Description

We ned the abilty to supply custom and default tag parsers when using cljs.reader/read-string (found in src/cljs/cljs/reader.cljs) in running ClojureScript applications.

ns prefixed tags

As per the edn specification "user tags must contain a prefix component". Currently, because (name tag) is being called, the ns prefix component is dropped when looking up the tag in *tag-table*

default reader fn

Currently, there is no support for supplying a default reader fn (akin to *default-data-reader-fn* in Clojure proper).

2 issues rolled into one?

I know this may be bad practice rolling 2 issues into one, but I do not know how to formulate the separate patches that affect the same lines of code and have the apply correctly regardless of order. If I need to correct this, please advise.

Already reported?

I know this issue was already raised in CLJS-335, but from my experience with making these modifications for a running ClojureScript app, I did not come across the fns in the files mentioned in that task. I assume this is because that had more to do with compiling cljs code, but please correct me if I'm wrong.

Along those lines, is this patch not acceptable if it doesn't fix both places at once?

Approach & Naming

I followed the approach that was already in place for tag parsers, supplying register and deregister helper fns. I was a bit torn on naming because in Clojure *default-data-reader-fn* is used, but in the existing ClojureScript code they are called tag-parser. Should the "reader" vs "parser" nomenclature be unified between Clojure and ClojureScript, or are they named differently because they are fundamentally different in some way that I am missing?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Nolen added a comment -

I don't think we can have a unified solution without a reader that is shared both at compile time and run time and I think the benefits today of run time support trumps the possible future convenience of compile time support. I don't think there is any good reason for the difference in naming - I'm inclined to keep things in line with Clojure as much as possible.

Happy to move forward with this one unless there are objections from others.

Show
David Nolen added a comment - I don't think we can have a unified solution without a reader that is shared both at compile time and run time and I think the benefits today of run time support trumps the possible future convenience of compile time support. I don't think there is any good reason for the difference in naming - I'm inclined to keep things in line with Clojure as much as possible. Happy to move forward with this one unless there are objections from others.
Hide
Permalink
kovas boguta added a comment -

My problem in CLJS-335 was that you couldn't compile cljs code with embedded user-defined tagged literals.

The code in this ticket is also great. But it would be even better if there was a generic function for reading tagged literals, known or unknown, that had the exact same argument structure as the the tag reader functions.

My solution for CLJS-335 is to read the TL into code that resolves and invokes the tag reader function on the CLJS side.

However it will fail for unknown tags, and will not fall back on the default reader functionality defined in the solution for this ticket. It would be trivial to fix this, if there was a single function that my solution can use that handled both known and unknown tags.

Otherwise, my solution can be extended with more code, to first check for a specific reader, and then fall back on the default reader.

Show
kovas boguta added a comment - My problem in CLJS-335 was that you couldn't compile cljs code with embedded user-defined tagged literals. The code in this ticket is also great. But it would be even better if there was a generic function for reading tagged literals, known or unknown, that had the exact same argument structure as the the tag reader functions. My solution for CLJS-335 is to read the TL into code that resolves and invokes the tag reader function on the CLJS side. However it will fail for unknown tags, and will not fall back on the default reader functionality defined in the solution for this ticket. It would be trivial to fix this, if there was a single function that my solution can use that handled both known and unknown tags. Otherwise, my solution can be extended with more code, to first check for a specific reader, and then fall back on the default reader.

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4#649-r158309) | Report a problem
Powered by a free Atlassian JIRA open source license for Clojure. Try JIRA - bug tracking software for your team.