Support defrecord reader tags
Description
Currently, defrecord instances print similar to how they do in clojure
This representation cannot be read by the compiler, nor at runtime by cljs.reader/read-string
Analysis
The two requirements - using record literals in cljs source code and supporting runtime reading - can be addressed by using the analyzer to find defrecords and registering them with the two respective reader libraries.
Record literals
Since clojurescript reads and compiles a file at a time, clojure's behavior for literals is hard to exactly mimic. That is, to be able to use the literal in the same file where the record is defined.
A reasonable compromise might be to update the record tag table after each file has been analyzed. Thus the literal form of a record could be used only in requiring files.
EDIT: Record literals can also go into the constant pool
cljs.reader
To play well with minification, the ^:export annotation could be reused on defrecords, to publish the corresponding reader tag to cljs.reader.
Related Tickets
Reusing the ^:export annotation interacts with http://dev.clojure.org/jira/browse/CLJS-1109
data_readers.cljc support http://dev.clojure.org/jira/browse/CLJS-1194 and http://dev.clojure.org/jira/browse/CLJS-335
Environment
Activity
We have both compiler support as well as reader support (thanks to relying on tools.reader).
This has been resolved for some time.
Trying my hand at this, but I'm stuck at an architecture conundrum.
Should the analyzer be able to add a tag reader to the tag table, or should the reader take a look at a the record-table to build tag readers on the fly?
The former seems easier to do with a macro, but it feels wrong to write reader code in the analyzer namespace.
The latter is more tedious because all the reader functions deref the tag reader table, so I'd have to go through all of them, but it feels less like a war crime than the former.
Or is there another option I'm not seeing?
It's preferred that we avoid exporting. Instead we can adopt the same approach as the constant literal optimization for keywords under advanced optimizations. We can make a lookup table (which won't pollute the global namespace like exporting does) which maps a string to its type.
I'm all for this enhancement.