Reading, representing, and printing tagged literals

[Brandon Bloom]

Hi all,

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.

Cheers,

Brandon

[Robert Pitts]

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.

[Gary Fredericks]

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.

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Gary Fredericks
(803)-295-0195
frederi...@gmail.com
www.gfredericks.com

[Mikera]

Hi Brandon,

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?

[Brandon Bloom]

> 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.