On Tue, Oct 16, 2012 at 2:41 PM, Herwig Hochleitner <hhochleit...@gmail.com>wrote:
> 2012/10/16 David Nolen <dnolen.li...@gmail.com> > >> None of the invocation optimizations make any sense for anything other >> that advanced optimization. > > > But the invokations in javascript output work even when not using google > closure at all, e.g. the REPL. > Yes because we don't try to optimize them. > > >> They hard code static assumptions that might get invalidated in any >> compilation unit other than whole program. >> >> Partially agree: I would call those hard coded static assumptions an ABI > (e.g. the naming convention for fixed arity invokations, or the invokation > of a protocol fn) and compilation units would only work, when the APIs they > consume have a matching ABI (this is true even now, you wouldn't compile > parts of your project with different versions of clojurescript, would you?). > Start a CLJS REPL with :static-fns true. Make a function called foo. Call it from a function bar. Redef foo w/ different arities. Now call bar. This will not work. Same if you redef foo to be an instance of a deftype that implements IFn. > We need declare, because clojure features a single pass compiler, and > sometimes we want to code mutual recursion without letfn. The moral > equivalent for the MM dead code issue would be a compiler flag to turn off > multimethods, right?. Certainly doable. If you'd like me to implement that > flag before turning to more comprehensive optimization, I'll do it. > Either the user used multimethods or they did not. If they did emit the hierarchy. And only bother with this code size optimization during advanced compilation - just always emit the hierarchy otherwise. > Please also note: I'm not proposing to get rid of the single pass > semantics of clojure. Quite the opposite. After the analyzer is done with > its single pass and has unambigously resolved everything, optimization > passes are free to optimize, since the semantics are already established. > Nothing I've said has anything do w/ optimization passes. Just how immediate problems could be solved without waiting for that ;) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
