http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/CLJ-1033 Clojure <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">user=&gt; (read-string (pr-str {(keyword <span class="code-quote">"key@other"</span>) :stuff})) RuntimeException Map literal must contain an even number of forms clojure.lang.Util.runtimeException (Util.java:170)</pre> </div></div> <p>pr-str emits "{:key@other :stuff}", which read-string fails to interpret correctly. Either pr-str needs to escape the @ symbol, or read-string needs to handle the symbol inside a keyword.</p> <p>Background: I'm passing a map with email addresses as keys through Storm bolts, which require a thrift-serializable form. Using the pr-str/read-string combo fails on these keys, so I've fallen back to JSON serialization. </p> Ubuntu 12.04 LTS; Java 1.7.0_05 Java HotSpot(TM) Client VM CLJ-1033

pr-str and read-string don't handle @ symbols inside keywords properly

Enhancement Minor Open Unresolved Unassigned Steven Ruppert reader Thu, 26 Jul 2012 11:25:38 -0500 Sun, 13 Jan 2013 22:58:37 -0600 Release 1.4 0 0 <p>The '@' character is not a legal character for keywords or symbols (see <a href="http://clojure.org/reader">http://clojure.org/reader</a>). Recategorized as enhancement request.</p> <p>Then why doesn't (keyword "keywith@") throw an exception? It seems inconsistent with your statement.</p> <p>It is a long standing property of Clojure that it does not throw exceptions for everything that is illegal.</p> <p>Yeah, but read-string clearly does. Is there a good reason that the "keyword" function <em>can't</em> throw an exception? With the other special rules on namespaces within symbol names, the "keyword" function really should be doing validation.</p> <p>Another solution would be to allow a ruby-like :"symbol with disallowed characters" literal, but that would also be confusing with how the namespace is handled.</p> <p><a href="https://groups.google.com/forum/?fromgroups=#!topic/clojure/Ct5v9w0yNAE">https://groups.google.com/forum/?fromgroups=#!topic/clojure/Ct5v9w0yNAE</a> has some older discussion on this topic. </p> <p>Disclaimer: I'm not a Clojure/core member, just an interested contributor who doesn't know all the design decisions that were made here.</p> <p>Steven, I think perhaps a couple of concerns are: (1) doing such checks would be slower than not doing them, and (2) implementing such checks means having to update them if/when the rules for legal symbols, keywords, namespace names, etc. change.</p> <p>Would you be interested in writing strict versions of functions like symbol and keyword for addition to a contrib library? And test suites that try to hit a significant number of corner cases in the rules for what is legal and what is not? I mean those as serious questions, not rhetorical ones. This would permit people that want to use the strict versions of these functions to do so, and at the same time make it easy to measure performance differences between the strict and loose versions.</p> <p>Looking back at this, the root cause of the problem is that the {pr} function, although it by default "print<span class="error">&#91;s&#93;</span> in a way that objects can be read by the reader" <span class="error">&#91;0&#93;</span>, doesn't always do so. Thus, the easiest "fix" is to change its docstring to warn that not all keywords can be read back.</p> <p>The deeper problem is that symbol don't have a reader form that can represent all actually possible keywords (in this case, those with "@" in them). Restricting the actually-possible keywords to match the reader form, i.e. writing a strict "keyword" <b>function</b> actually seems like a worse solution overall to me. The better solution would be to somehow extend the keyword reader form to allow it to express all possible keywords, possibly ruby's :"keyword" syntax. Plus, that solution would avoid having to keep hypothetical strict keyword/symbol functions in sync with reader operation, and write test cases for that, and so on.</p> <p>Thus, the resolution of this bug comes down to how far we're willing to go. Changing the docstring would be the easiest, but extending the keyword form would be the "best" resolution, IMO.</p> <p><span class="error">&#91;0&#93;</span>: <a href="http://clojuredocs.org/clojure_core/clojure.core/pr">http://clojuredocs.org/clojure_core/clojure.core/pr</a></p> Approval Vetted Global Rank