The special but important case of compiling clojurescript also raises some issues.
When clojurescript source code is read, this is done by clojure, and thus the clojure tag readers apply. Currently they are re-bound to read the tag literals into clojurescript source code which, when executed, create the corresponding object. There are two problems with this 1. you have the definition of the cljs tags in 2 places, 1 in clj during compile, and 1 in cljs during runtime 2. you have to manually juggle which readers clj should use when (this can be a real problem for the cljs toolchain) The root problem is that there is no representation of tagged literals other than as strings, which is the problem we are trying to solve here. Instead of serializing objects directly into eg #inst "2012-01-01" , they could first be converted into a GenericLiteral type, and then appropriately dealt with by the cljs emitter (which will emit code to resolve the tag name at runtime) So the procedure for creating user-defined tagged literals could be: a) implement a function that takes data and returns the constructed datastructure, b) implement a protocol to generate a GenericLiteral from the constructed datastructure. In addition to solving the above problems, it is simpler, easier, and less error prone than forcing the user to assemble the string themselves. It is also forward-compatible with more compact binary representations of clojure data. On Mon, Jul 16, 2012 at 7:03 PM, kovas boguta <kovas.bog...@gmail.com> wrote: > Bumping this thread, since this is becoming more of a blocker for my > efforts with Session. > > I think there are three operations you want to do on the unknown > literal wrapper: > 1. print/serialize it (this would just output the original string you read in) > 2. get the tag name > 3. get the uninterpreted data structure > > I think the wrapper should be a datatype rather than an ordinary > collection. That way, if you try to manipulate it, it will fail > immediately and in an obvious way. If it is a collection, there is a > potential for conflict if the "intended" tagged literal interpretation > implements some of the same protocols as the collection. > > The minimal protocol could look like > (defprotocol IUnknownLiteral (literal-name [this]) (literal-data [this]) > > and then you would simply have > (deftype UnknownLiteral [name data] > IUnknownLiteral > (literal-name [this] name) > (literal-data [this] data)) > > (In the cljs case it can also implement the printing protocol (which > doesn't exist in clj), though thats an implementation detail.) > > Other names could be: (Generic|Undefined|Inert)(Literal|Data|Tag) > > The only conceptual issue is what to do with metadata. > > Should the UnknownLiteral be allowed to have its own metadata? Or > should it attempt to delegate it's metadata to whatever metadata was > originally associated with its literal-data? > > If it has it's own metadata, this will be lost upon re-serialization. > Delegating to the literal-data will not work when the literal-data is > not a type that supports metadata. > > The middle ground is to allow it to have its own meta data, and upon > serialization, just attach it to its literal-data, and upon > deserialization you get what you get. This may be the best option, but > this feels like a pretty hypothetical question. > > It might be best to just not do anything with metadata right now and > decide later once there is some experience. > > thoughts? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
