|Reading, representing, and printing tagged literals||Brandon Bloom||5/23/13 8:31 AM|
I've encountered some personal confusion and some confused folks on IRC when it comes to EDN and tagged literals. I've also found that using tagged literals isn't as pleasant as it could be: It's very difficult to implement a type that correctly round-trips to a printed tagged literal form. Furthermore, the lack of an in-memory representation for tagged literals hurts the toolability of EDN.
I've written up some notes and a proposed solution here: http://dev.clojure.org/display/design/Representing+EDN
Would love to hear thoughts on this.
|Re: Reading, representing, and printing tagged literals||Robert Pitts||5/24/13 7:39 AM|
I've felt the pain around 1 and 3 in the past, I'll take your word on issue 2.
Having not seriously thought about this, your proposed solution looks good to me... but I'm mostly here just to +1 your raising of the issue.
|Re: Reading, representing, and printing tagged literals||gfredericks||5/24/13 7:57 AM|
I also +1 interest in the issue. I've avoided using tagged literals on several occasions because it wasn't worth messing with print-method.
|Re: Reading, representing, and printing tagged literals||Mikera||5/29/13 7:45 PM|
Here's an example use case (from a core.matrix perspective)
1. Support reading/writing types we don't control, e.g. javax.vecmath.GMatrix
2. Ability to round-trip such types to a tagged literal representation
3. Possibility for others to have different representations of the same type (likely needed for composing libraries...)
4. Would be nice to decouple this from print-method
5. If reading in a context where the type isn't available, fallback to a default reading function
Basically I would like to be able to code "read-edn-matrix" and "write-edn-matrix" so that they behave sanely, work for types we don't control and don't cause any conflicts with anything else.
Would your proposed design support this?
|Re: Reading, representing, and printing tagged literals||Brandon Bloom||5/29/13 8:03 PM|
> types we don't control
That's tricky for the same reasons extending protocols to types you don't control is tricky.
Reading tagged literals is configured via two dynamic vars: 1) a map of symbols to readers and 2) a fallback function.
Writing tagged literals could similarly be configured by a map of types to writers and a fallback function.
That would be more flexible than a protocol. I'll add a note to the design page.