I've implemented the fixes as suggested and created 3 tickets with patches:
1) Omit var statements http://dev.clojure.org/jira/browse/CLJS-397
Except for the new js rendered by stack traces on the repl, this should be
a no brainer
2) Create a new macro extend-instance
http://dev.clojure.org/jira/
On Tue, Oct 16, 2012 at 5:38 PM, Herwig Hochleitner
wrote:
>
> 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.
>
Sounds good!
>
>
>> Please also note: I'm not
2012/10/16 David Nolen
>
>> 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 straightforwar
On Tue, Oct 16, 2012 at 2:41 PM, Herwig Hochleitner
wrote:
> 2012/10/16 David Nolen
>
>> 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
2012/10/16 David Nolen
> 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.
> They hard code static assumptions that might get invalidated
None of the invocation optimizations make any sense for anything other that
advanced optimization. They hard code static assumptions that might get
invalidated in any compilation unit other than whole program.
We don't need to look at the whole program at once. Think about why we need
declare and
2012/10/16 David Nolen
>
> ClojureScript programmers benefit from the assumption of whole program
> optimization for production code. Also remember we have analyze-file.
>
>
They most certainly do, but in my mind this assumption is only made in the
google closure compiler, right now.
I see analyz
On Tue, Oct 16, 2012 at 12:27 PM, Herwig Hochleitner wrote:
> 2012/10/16 David Nolen
>
>>
>> I'm aware of this one as well. But again I think we can and should do a
>> quick fix in the compiler for this. Either the user used multimethods or
>> they did not.
>>
>
> I don't see how such a quick fi
2012/10/16 David Nolen
>
> I'm aware of this one as well. But again I think we can and should do a
> quick fix in the compiler for this. Either the user used multimethods or
> they did not.
>
I don't see how such a quick fix could be done, without the compiler
gaining a concept of "the whole pro
On Tue, Oct 16, 2012 at 7:19 AM, Herwig Hochleitner
wrote:
> Certainly, such a simple optimization (omitting var reads in a statement
> context) could live in the emitter.
> The next stumbling block to a smaller clojurescript, however, is the
> global-hierarchy var, which doesn't get removed by th
2012/10/16 David Nolen
>
> Yep I think there are quite a few things like this. But I don't think we
> need an optimization pass for this paticular case (and I'm not saying
> that's not a good idea - see below). Hopefully we can a direct patch for
> this issue around top level deftypes/records.
>
On Mon, Oct 15, 2012 at 10:14 PM, Herwig Hochleitner wrote:
> When investigating what the closure compiler does with cljs output, I
> discovered the following:
>
> Google closure does not eliminate unused var reads. This means that e.g. a
> deftype
>
> (deftype A [])
>
> which compiles to
>
> wor
When investigating what the closure compiler does with cljs output, I
discovered the following:
Google closure does not eliminate unused var reads. This means that e.g. a
deftype
(deftype A [])
which compiles to
workbench.foo.A = (function (){
snip
});
workbench.foo.A; // <-- beca
13 matches
Mail list logo
