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-1100 Clojure <p>The LispReader tries to read a record instead of a literal if the tag contains periods:</p> <p><a href="https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java#L1171">https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java#L1171</a></p> <p>Which effectively means that reader tags cannot contain periods.<br/> The EDN spec is unclear on this: </p> <blockquote><p>edn supports extensibility through a simple mechanism. # followed immediately by a symbol starting with an alphabetic character indicates that that symbol is a tag.</p></blockquote> <p>(issue opened: <a href="https://github.com/edn-format/edn/issues/39">https://github.com/edn-format/edn/issues/39</a>)</p> <p>If periods are allowed, then the LispReader should first check to see if the tag is in <tt>&#42;data-readers&#42;</tt> and only then if not try to initialize a Java class.</p> <p>I'm happy to write the patch if this behavior is what is desired.</p> CLJ-1100

Reader literals cannot contain periods

Defect Major Open Unresolved Unassigned Kevin Lynagh reader Fri, 2 Nov 2012 23:57:22 -0500 Thu, 14 Feb 2013 15:04:53 -0600 1 2 <p>The suggested patch (clj-1100-reader-literal-periods.patch) will break reading records when &#42;default-data-reader-fn* is set. Try adding a test like this:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">(deftest tags-containing-periods-with-<span class="code-keyword">default</span> ;; we need a predefined record <span class="code-keyword">for</span> <span class="code-keyword">this</span> test so we (mis)use clojure.reflect.Field <span class="code-keyword">for</span> convenience (let [v <span class="code-quote">"#clojure.reflect.Field{:name \"</span>fake\<span class="code-quote">" :type :fake :declaring-class \"</span>Fake\<span class="code-quote">" :flags nil}"</span>] (binding [*<span class="code-keyword">default</span>-data-reader-fn* nil] (is (= (read-string v) #clojure.reflect.Field{:name <span class="code-quote">"fake"</span> :type :fake :declaring-class <span class="code-quote">"Fake"</span> :flags nil}))) (binding [*<span class="code-keyword">default</span>-data-reader-fn* (fn [tag val] (assoc val :meaning 42))] (is (= (read-string v) #clojure.reflect.Field{:name <span class="code-quote">"fake"</span> :type :fake :declaring-class <span class="code-quote">"Fake"</span> :flags nil})))))</pre> </div></div> <p>The problem assessment is ok, but the resolution approach may not be. What happens should be based not upon what is in data-readers but whether or not the name names a class.</p> <p>Is the intent here to allow readers to circumvent records? I'm not in favor of that.</p> <p>New patch following Rich's comments. The decision to read a record is now based on the symbol containing periods and not having a namespace. Otherwise, it is considered a data reader tag. User<br/> defined tags are required to be qualified but they may now have periods in the name. Tests added to show that<br/> data readers cannot override record classes. Note: Clojure-defined data reader tags may be unqualified, but they should not contain periods in order to avoid confusion with record classes.</p> <p>I deleted my old patch and some comments referring to it to avoid confusion.</p> <p>In Clojure 1.5 beta 1, # followed by a qualified symbol with a period in the name is considered a record and causes an exception for the missing record class. With the patch, only non-qualified symbols containing periods are considered records. That allows user-defined qualified symbols with periods in their names to be used as data reader tags.</p> <p>clj-1100-periods-in-data-reader-tags-patch-v2.txt dated Feb 7 2013 is identical to <a href="http://dev.clojure.org/jira/browse/CLJ-1100" title="Reader literals cannot contain periods">CLJ-1100</a>-periods-in-data-reader-tags.patch dated Nov 29 2012, except it applies cleanly to latest master. The only change appears to be in some white space in the context lines.</p> <p>I've removed clj-1100-periods-in-data-reader-tags-patch-v2.txt mentioned in the previous comment, because I learned that <a href="http://dev.clojure.org/jira/browse/CLJ-1100" title="Reader literals cannot contain periods">CLJ-1100</a>-periods-in-data-reader-tags.patch dated Nov 29 2012 applies cleanly to latest master and passes all tests if you use this command to apply it.</p> <p>% git am --keep-cr -s --ignore-whitespace &lt; <a href="http://dev.clojure.org/jira/browse/CLJ-1100" title="Reader literals cannot contain periods">CLJ-1100</a>-periods-in-data-reader-tags.patch</p> <p>I've already updated the JIRA workflow and screening patches wiki pages to mention this --ignore-whitespace option.</p> <p>Both of the current patches, <a href="http://dev.clojure.org/jira/browse/CLJ-1100" title="Reader literals cannot contain periods">CLJ-1100</a>-periods-in-data-reader-tags.patch dated Nov 29 2012, and clj-1100-reader-literal-periods.patch dated Nov 6 2012, fail to apply cleanly to latest master (1.5.0-RC15) as of today, although they did last week. Given all of the changes around read / read-string and edn recently, they should probably be evaluated by their authors to see how they should be updated.</p> <p>I deleted my patch: <a href="http://dev.clojure.org/jira/browse/CLJ-1100" title="Reader literals cannot contain periods">CLJ-1100</a>-periods-in-data-reader-tags.patch. clj-1100-reader-literal-periods.patch is clearly wrong, but the original author or an administrator has to delete that.</p> <p>I cannot figure out how to remove my attachment (clj-1100-reader-literal-periods.patch) in JIRA.</p> <p>Downarrow (popup) menu to the right of the "Attachments" section. Choose "manager attachments".</p> <p>Great, thanks Steve. Are you going to take another pass at this issue, or should I give it a go?</p> <p>Kevin, I'm not planning to work on this right now as 1.5 is pretty much done. It might be worthwhile discussing the issue a bit on the dev mailing list before working on a patch, but that's up to you. I think my approach was correct, although now changes would have to be applied to both LispReader and EdnReader.</p> Approval Vetted Global Rank