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

Reply via email to