2014-08-04 16:27 GMT+02:00 David Nolen <dnolen.li...@gmail.com>:
>
> We don't gensym let bindings - the shadowing logic was added to create
> stable names.
In fact, we do within statement contexts. I wrote that as a fix for the case
(do (let [x 1] (fn [] x))
(let [x 2] (comment clobbered x in fn)))
(as well as toplevel lets) as part of CLJS-401 and it is still in place:
https://github.com/clojure/clojurescript/commit/234bd3a85213d98595090b3a6625f0aeae7ea6ed
Im sure that this could be subsumed by your work on stable renaming (which
it pre-dated), but then the debugger issue would need additional work, see
below.
This will be useful if anyone wants to create more
> powerful debuggers for ClojureScript. That said for self reference
> using an implicitly shadowed name would seem to avoid these issues,
> i.e. console__0.
>
Point taken. Let me sidetrack a bit on the gensymming I introduced, in
order to aid a hypothetical effort seeking to remove it.
I get that we would like a debugger to predict the generated js names from
a piece of cljs source without access to the original analyzer environment.
Premise: Would you agree that such a mechanism only makes sense if it works
with isolated toplevel forms, a la REPL?
I.E. the debugger shouldn't need to reanalyze the whole program to get at a
given name assignment, but just the toplevel form at hand. That makes
sense, right?
Then, even with your scheme of keeping a separate gensym counter for every
var name, there's a choice between fire and frying pan:
1) Wrap (at least) toplevel lets into (function(){..}()) (IIRC, David, you
rejected this approach to CLJS-401 because of the "minimal wrapping"
philosophy)
2) Keep the initial counters for each (toplevel) form in some kind of
source map, e.g. code comments
Given that js 1.5 has no direct let-equivalent, every toplevel form
closing over some var 'x' will need to know about every previous toplevel
form closing over another var 'x' (with the same name).
So this is pretty much on par with gensymming, in terms of effort
required to book-keep var names.
In essence, removing my gensym and going with just the predictable counters
means that you can't reset the counters when a let closes (only when an fn
closes).
So in general because a let can occur toplevel, solution 2) means that you
have to treat all sources as one giant do - statement, maybe defining
explicit breaking points for the debugger via source map.
I think that this decision is fundamental i.e. TINA, but I would love to be
convinced otherwise.
Given all that + the intuition that closure and/or jit eats
(function(){}())s for breakfast, let me repropose to go with fire (solution
1).
Maybe a separate ticket?
kind regards
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
