semiauto-resolving keywords and edn

[tomoj]

I have a patch for EdnReader which enables the following behavior: https://www.refheap.com/paste/43476cfab0a829957d6e1967f

You can pass read-edn an :alias map in opts, which maps namespace alias symbols (or nil for keywords like "::foo") to their resolved namespace symbols:

(read-edn-string {:aliases {'foo 'com.example.foo, nil 'com.example}} "[::foo ::foo/foo]")
;; [:com.example/foo :com.example.foo/foo]

An :alias-default function can also be provided which will be called with an unresolved keyword, returning whatever the entire aliased keyword should read to. The nil key seems funky (maybe a separate option instead?), and I think it may be wrong that if alias-default returns nil, an "invalid token" exception is thrown.

Here's the patch I've got so far: https://www.refheap.com/paste/11132

I've tested this for Datomic schema .edn files. With this patch, I find it more bearable to use longer namespaces. In code interacting with the schema,

I can see, though, that ::keywords were intentionally left out of edn. Why?

I'd also like Namespace-decoupled aliasing for LispReader, since my ident namespaces do not always correspond to Namespaces, but I'd like to alias them in Datomic code (also, there is the separate case of ClojureScript macros). For now I'll just keep using shorter (and more collision-prone) namespaces, or just accept the noise of longer namespaces. The utility of namespaced schema idents is definitely more important to me than reducing this noise.

[Herwig Hochleitner]

Actually this lead me to the following discovery: Right now, EDN is a superset of Clojure.

The reason: ::keyword is not forbidden in the EDN spec, but also has no special meaning is defined, hence it would be read as a keyword with the name ":keyword" (vis a vis :foo:bar)

However, the clojure reader would automatically resolve that to :<whatever-current-namespace>/keyword

Luckily, in -RC15 (edn/read-string "::foo") throws, because otherwise that would be another side-channel.

Regarding the patch:

For the first step, I think we should just define what ::keyword means in EDN. I.e. the null key in your aliases map.

Is it an error or do we introduce a default namespace to the EDN spec?

Then, I think an attempt to enable namespace resolution in clojure.edn should also encompass a strategy for symbols.

[Herwig Hochleitner]

Third option:

Leave the EDN spec as is and update clojure.edn to actually read ::keyword as (keyword ":keyword")

I omitted that from my first response, since I don't like proposing to create a syntactic incompatibility between clojure.core/read and clojure.edn/read. BUT

A default namespace in the EDN spec sucks and one can post-process output of edn/read anyways.

2013/2/11 Herwig Hochleitner <hhochl...@gmail.com>

[davesann]

Since the namespace is indeterminate - I would suggest that ::keyword should just not be allowed.

Better to be explicit - if you intended a particular namespace - say so.

Dave

[Rich Hickey]

Aliases might be interesting for edn, but your use of ::alias/name has no precedent in Clojure. :: implies a single default context. ::alias/name would require that people know when they were using an alias, which somewhat defeats the point.

Currently edn has no context-sensitive reading other than tagged literals.

In any case, you can't introduce an alias system without introducing a mechanism for defining them. Clojure has that in e.g. namespaces, and code would have that in your example via API. But edn does not have that, in the same way that e.g. XML can embed namespace declarations. Doing the same for edn is a bit trickier as it has object-at-a-time semantics (and thus can stream) vs document semantics.

Rich

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

[Rich Hickey]

On Feb 11, 2013, at 6:53 AM, davesann wrote:

> Since the namespace is indeterminate - I would suggest that ::keyword should just not be allowed.

For now, agreed. Could you please make a ticket here:

https://github.com/edn-format/edn/issues

The actual logic for keywords is : immediately followed by a legal symbol (which would e.g. disallow ::foo), but the spec doesn't quite say that.

Thanks,

Rich

[davesann]

https://github.com/edn-format/edn/issues/44