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/CLJS-289 ClojureScript <p>See discussion here: <a href="https://groups.google.com/d/topic/clojure-dev/vZLVKmKX0oc/discussion">https://groups.google.com/d/topic/clojure-dev/vZLVKmKX0oc/discussion</a></p> <p>Summary: Duplication of ast nodes in various keys and in :children is problematic for some users. In particular, it doesn't play nicely with printing. A solution is needed which preserves "The AST is data. Period."</p> <p>The attached patch makes no changes to how the sub nodes are currently stored outside of the :children key. Instead, it replaces :children values with a vector of keys into the main ast node. This preserves child ordering and allows a children function to be defined as:</p> <p>(defn children <span class="error">&#91;ast&#93;</span><br/> (mapcat #(if (coll? %) % <span class="error">&#91;%&#93;</span>) ((apply juxt (:children ast)) ast)))</p> <p>The attached patch has two caveats: 1) Many (but not all?) blocks will now be present in the children hierarchy as 'do forms. 2) Interleaved forms are intentionally bugged with respect to ordering. The :children vector for those forms match the actual behavior, not the expected behavior. This can be fixed along with <a href="http://dev.clojure.org/jira/browse/CLJS-288">http://dev.clojure.org/jira/browse/CLJS-288</a></p> CLJS-289

Represent ast :children as a vector of keys

Enhancement Major Resolved Declined Unassigned Brandon Bloom patch patch, Thu, 31 May 2012 17:51:17 -0500 Wed, 29 Aug 2012 00:09:12 -0500 Tue, 5 Jun 2012 08:09:05 -0500 0 3 <p>the result of the discussion did not end with agreement on representing :children as a vector of keys</p> <p>I realize that, but it was one approach suggested and seemed entirely viable, so I tried it. From what I can tell, it seems like a solution that meets all of the criteria that came up during the discussion.</p> <p>Did I overlook a requirement?</p> <p>Who is currently using :children and could weigh in on whether or not this still meets their needs?</p> <p>I'm using :children and I don't think this patch (currently) meets my needs. At least {:op :let ...} is broken IMO. (something like `(map :init bes)` is missing from the patch) </p> <p>Ah OK, you're right. It's the same problem there that I ran into with :statements and analyze-block: There is a pseudo AST node that needs to be traversed down into.</p> <p>The easy fix for that here would be to merge {:children <span class="error">&#91;:init&#93;</span>} into each binding, but the binding hash will be missing :op and :form. For analyze-block, I was able to use :op :do and :form (list 'do ...), but there isn't an obvious analogy here without inventing a :binding op or relaxing the requirement for :op and :form.</p> <p>Interestingly, each successive binding can be treated as a single nested binding. What if we defined let as a macro which expands to a series of let1 forms? (let <span class="error">&#91;x 1 y 2&#93;</span> (* x y)) --&gt; (let1 <span class="error">&#91;x 1&#93;</span> (let1 <span class="error">&#91;y 2&#93;</span> (* x y))</p> <p>That may increase the depth of the AST, but it would really simplify traversal into binding clauses. Each let op would have :name, :init, and children as <span class="error">&#91;:init&#93;</span>.</p> <p>In general, it may be worth while to consider doing the same thing with the various analyze-blocks situations, such that 'do is the only place multiple statements can occur.</p> <p>Er, I mean: a hypothetical let1 op would have children <span class="error">&#91;:init :statements :ret&#93;</span></p> <p>However, if you also expanded the implicit do blocks, you'd be able to simplify to <span class="error">&#91;:init :body&#93;</span> or something like that.</p> <p>Forgive me for repeatedly commenting, but it also occurs to me that you can change 'do to a macro which expands to a series of 'do2 forms:</p> <p>(do x y z) --&gt; (do2 x (do2 y z)) or (do2 (do2 x y) z)</p> <p>That do2 op could have children <span class="error">&#91;:left :right&#93;</span> and all other :statements and :ret children could be simplified down to 'do2 expansions.</p> <p>With that in mind, the children fn becomes simply (defn children <span class="error">&#91;ast&#93;</span> ((apply juxt (:children ast)) ast)) and a lot of analyze and emit code gets much simpler by not having to map over many collections all over the place.</p> <p>Kinda a wild idea and probably not the right forum for it, but worth suggesting. Thoughts?</p> <p>I see little benefit to changing core macros. I also see no problem with creating a :binding ast node.</p> <p>Every node (i.e. an map with :op, :form and :env keys, called an "Expression Object" in the docstring for analyze) in ClojureScript corresponds to a self-contained expression. A binding form is not self-contained, it is a part of the let expression.</p> <p>Another similar example is functions. There is a node {:op :fn ...} but there is no {:op :fn-method} even thou there are maps under the :methods key describing function methods. The same argument goes for this: A function method is not self-contained, it is part of the function and should not be a node.</p> <p>The nodes (expression objects) which make up the ClojureScript AST seems to be really well thought out and I would be careful in making the proposed change.</p> <p>Agreed I think it's far too early to have a ticket for this. Confluence page first.</p> <p>Design page here: <a href="http://dev.clojure.org/display/design/AST+children">http://dev.clojure.org/display/design/AST+children</a></p> Global Rank Patch Code