2012/10/16 David Nolen <dnolen.li...@gmail.com> > >> 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. >
And suppose one tried to optimize them: With an established concept of compilation units, it's straightforward to optimize invokations within a unit and keep a compatible invokation ABI of its public members with following effect: - single form units (REPL) work - whole program units (Clojurescript) work - namespace/file units (Clojurescript with a JVM backend, hypothetically) work Again, getting ahead of myself here. > 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. > Thanks for raising that point. So IFn call is different from an aritiy call is different from a protocol call in clojurescripts informally defined ABI (with :static-fns). This has to be considered when thinking about compilation units. > 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. > The emitter still can not look ahead in its single pass, but thinking about it, it seems to me your proposal could be implemented by lazily initializing global-hierachy in derive. > 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 ;) > Ack, I think I'll try the two simple fixes first ;) -- 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
