edn-java should provide a way to write edn

[mikera]

A few thoughts on this:

• It would be useful to let people define their own writers for their own classes. Something like ednWriter.registerWriter(MyClass.class, new CustomWriter() {......})
• Should be possible to provide default writers for the usual Java collection interfaces (Map, List, Set) as well as the obvious primitive values
• There is a bit of an oddity regarding how to write a java.util.List - should it be output list or a vector? perhaps ArrayList should map to vector and any other list map to a list by default?
• We should be able to round-trip reliably i.e. write(anything) == write(read(write(anything)))

[mikera]

Some more thoughts:

• The writer object should be immutable (it would be useful to share, this would avoid concurrency issues etc.)
• It would be nice if it is compatible with Clojure data structures (although I'm not sure how easy this is to achieve unless we add Clojure as a dependency which is obviously not a good idea....)

[bpsm]

• Yes, the writer will need to allow users to register logic to handle their own tagged types.
• Map, List, Set will be built-in to the Writer. I don't plan to make them customizable initially.
• In deciding between [] and (), I considered making that depend on RandomAccess, but I haven't really thought it through. Maybe we'll just write everything as [] initially.
• Yes, round-tripping must be possible.
• edn-java should not pull in dependencies, but since Clojure's data structures implement List, Set, Map etc, I don't see any reason why they would not be supported out of the box.

[mikera]

Sounds good on all the above although I think the list/vector distinction will need to be tackled in order for round-tripping to work.

Using RandomAccessList is an interesting idea to differentiate lists and vectors. I think it should work. But then we'd need to either:

• Go back to LinkedList as an underlying list implementation to avoid implementing RandomAccess
• Add our own immutable collection types with the appropriate semantics (e.g. EdnList and EdnVector)

Let me know if you want a quick immutable list / vector implementation for this purpose, happy to provide.

[bpsm]

Depends on what you mean by "round trip". Data structure should be equal after parsing, writing out, and parsing again: parse(write(parse(text))) should equal parse(text).

This works in Java even if we don't preserve the distinction between () and [] because of the way that List.equals() is specified. But, naturally, it would be desirable to preserve the ()/[] distinction if possible.

I still find it's too early to begin implementing a writer. I still want to do some research on how this has been tackled in other projects. (JSON comes to mind). In particular, I'm looking for a good way to layer the implementation similarly to the Parser/Scanner layering. Still something I'm thinking about.

[mikera]

I guess as a user of the library I would expect a round trip to preserve the [] / () distinction. It would be very counter-intuitive for this not to be preserved!

[bpsm]

"I guess as a user of the library I would expect a round trip to preserve the [] / () distinction. It would be very counter-intuitive for this not to be preserved!"

Yes, that's true. It would feel like a second-class implementation otherwise, but that still means solving the problem of how to differentiate on the java side. So far, RandomAccess seems like the simplest idea.

[mikera]

My suggestion would be to make RandomAccess the default, but expose enough configurability that the user can change this if desired (this is the same functionality that will be needed anyway to provide tagged types).

If you are researching this, I would strongly recommend taking a look at how Kryo does it: they have a good system for allowing people to register custom serializers for different types that override the default serialization. Also their implementation is extremely fast/efficient.

• http://code.google.com/p/kryo/