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-297 ClojureScript <p>The attached patch eliminates the :meta, :set, :vector, and :map ops.</p> <p>These four operations can be defined more simply in terms of<br/> calls to with-meta, set, vector, and hash-map respectively.</p> <p>The compiler was optimizing construction of vectors and maps. Now,<br/> those optimizations are implemented as macros. Additionally, sets<br/> are optimized in much the same way.</p> <p>3 files changed, 52 insertions<img class="emoticon" src="http://dev.clojure.org/jira/images/icons/emoticons/add.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>, 99 deletions<img class="emoticon" src="http://dev.clojure.org/jira/images/icons/emoticons/forbidden.gif" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Also worth mentioning: as macros instead of ops &amp; emit methods, these optimizations can apply to any backend. The macros create ClojureScript forms, rather than manually generating JavaScript.</p> CLJS-297

Eliminate :meta, :vector, :set, and :map ops

Enhancement Trivial Open Unresolved Unassigned Brandon Bloom patch patch, Sun, 3 Jun 2012 20:17:47 -0500 Fri, 31 Aug 2012 09:24:51 -0500 0 2 <p>I'd also like to extend this for Symbols and Keywords.</p> <p>I've been experimenting with fleshed out Symbol and Keyword objects with interning. I've found that I need emitters, macros, and functions. With the approach here, I could eliminate the emitters and instead have the analyzer produce invocation forms.</p> <p>I think this is an interesting patch. It would be worth adapting it to the decoupled emitters. It raises the question of how it would be possible to share part of the emitters between backends.</p> <p>I don't see many benefits falling out of this patch. How to best emit language primitives like literals and constants may vary from host to host - perhaps emitting bytecode directly will work best for some implementations. </p> <p>Couldn't macros emit bytecode via a mechanism similar to the js* form?</p> <p>My goals with this are:</p> <p>1) Move some optimizations from the emit phase further down the pipeline. For example, consider choosing the best associative data structure to create. Why should {:foo "bar"} be optimized to an ObjMap or ArrayMap but (hash-map :foo "bar") not be? Why should that optimization be implemented in such a way that it can not be reused by alternative backends?</p> <p>2) Operate at a higher level. Prefer working with Clojure forms over target-language code fragments (either strings or byte codes). This is where the code length savings is coming from.</p> <p>If we continue with this approach, I see 4 or 5 more places where analyzer &amp; emitter code can be replaced with shorter, simpler macros, which are more readily reused by alternate backends.</p> <p>The one implication (downside?) this approach has on consumers of the analyzer or API is that they may need to do a little extra work when considering :invoke operations for static analysis and the like. However, that seems likely for most analyzers anyway, so this would be a matter of (defmethod handle-special-form :map) vs (defmethod handle-invoke :hash-map)</p> <p>Re: 1, I don't think we should be "optimizing" <tt>hash-map</tt> or <tt>array-map</tt> (or similar) calls. These functions are a documented way of requesting a map of a particular type (see the docstrings) which I think should not be removed. If anything, we might want to introduce an <tt>obj-map</tt> function to create arbitrarily large ObjMaps on request (in fact I'll look into that, but that is a separate discussion).</p> <p>Additionally, the fact that {} is optimized to be a ObjMap in CLJS goes to show that any map-emitting macro will need to be rewritten for each target platform (ObjMap only makes sense when targeting JS, so this optimization simply won't be applicable to other backends). If so and assuming <tt>hash-map</tt> &amp; Co. retain the behaviour advertised in their docstrings, there's not much gain to implementing this in a macro over just writings a bunch of emitters.</p> <p>As for decoupling emitters &#8211; I think it's perfectly fine for them not to be decoupled, they are the layer closest to the platform after all. Certainly if there's some code which turns out to look the same across multiple platforms it might be worth it to move it upwards in the stack (not necessarily, though &#8211; moving it sideways, to a utility namespace / library, might turn out to be more appropriate), but I have a feeling this is an issue best decided once there actually are multiple backends in place and the various costs and benefits can be judged properly.</p> <p>Now, the story might well be different if we were to introduce some generic factory functions &#8211; "create a map of some type", "create a set of some type" etc. &#8211; if (and only if!) they would be meant for public consumption. Then implementing a bunch of compiler macros around those new factories and letting them handle data structure literals would save some duplicate work. I don't want to pronounce an opinion on the usefulness of such generic factory functions at this time &#8211; just pointing out the possibility.</p> <p>&gt; These functions are a documented way of requesting a map of a particular type</p> <p>D'oh! You're right.</p> <p>&gt; we might want to introduce an obj-map</p> <p>I see you did just that with <a href="http://dev.clojure.org/jira/browse/CLJS-322" title="Introduce an obj-map function as an analogue of array-map"><del>CLJS-322</del></a> &#8211; nice.</p> <p>&gt; the story might well be different if we were to introduce some generic factory functions</p> <p>There are already <b>some</b> generic factory functions. 'set, for example, is documented as "Returns a set of the distinct elements of coll." despite always returning a PersistentHashSet. Similar for vector and some others. It seems like map is the only core data structure that realistically has several reasonable choices for a default representation.</p> <p>&gt; implementing a bunch of compiler macros around those new factories and letting them handle data structure literals would save some duplicate work</p> <p>So all this was somewhat inspired by tagged_literals.clj &#8211; You'll see that those functions are effectively macros which take a form and, generally, return an invocation form.</p> <p>In my mind, I see Clojure's sugar syntax as a strict expansion transformation.</p> <p>For example, ^:m {:x <span class="error">&#91;@y &#39;z/w true&#93;</span>} is simply a shortcut for:</p> <p>(with-meta (make-map (keyword "x") (vector (deref y) (symbol "z" "w") Boolean/TRUE)) (make-map (keyword "m") Boolean/TRUE))</p> <p>This sort of thing already happens for @ derefs, # lambdas, etc.</p> <p>In theory, this could be implemented at a level lower than the compiler. You could, for instance, define a reader "desugar" mode which only returns lists and primitives instead of vectors, maps, etc. This would greatly reduce the number of special forms in the compiler, since all of these boil down to invocations with macros.</p> <p>Emit methods could be replaced with macros for at least these things: vars, maps, vectors, sets, nil, bools, regexes, keywords, symbols, metadata, and empty lists.</p> <p>The result would be a significant reduction in the amount of code in the compiler for a proportionally smaller increase in the amount of code in per-language macros and maybe the reader.</p> <p>&gt; I have a feeling this is an issue best decided once there actually are multiple backends in place</p> <p>I'll grant you that.</p> <p>I've said my piece on the topic and don't feel very strongly about this particular patch. I just wanted to spark the discussion about reusing more bits of the compiler between backends. In my mind, it's almost always preferable to transform lists than it is to emit strings. I tried that, and the result was a reduction in responsibilities for the analyzer and macros that were easier to work with than emit methods.</p> <p>Some further discussion here:</p> <p><tt><a href="http://clojure-log.n01se.net/date/2012-06-24.html#20:30a">http://clojure-log.n01se.net/date/2012-06-24.html#20:30a</a></tt></p> <p>One other advantage of function application over special casing maps/sets/etc is that argument evaluation order is well defined for function application (left-to-right). The Clojure reader returns un-ordered maps &amp; sets, so without changing the reader, we have no way of being able to know what order map key-value-pairs or set elements were originally in. I filed a bug on that. I think we need to make the reader extensible to say to create the return values from their children expressions. In the case of the ClojureScript compiler, we do care about order, so we'd want to return either a (make-map ...) form directly, or a sorted-map by read-order. Same goes for sets.</p> <p>There's not enough rationale for this one.</p> Global Rank Patch Code