On Jan 11, 3:55 am, Daniel Werner <daniel.d.wer...@googlemail.com>
wrote:
> Hi Ram,
>
> your take on Clojure to JS translation seems very interesting to say
> the least. Thanks for sharing your work.
You're very welcome, and thanks for the quick feedback.
> A few points I tripped over while reading the example:
> * Why are functions being defined as "join = function (...)" instead
> of "function join (...)"? Does this make a semantic difference?
This stems from my misunderstanding of Clojure's `defn' form. I had
started implementing Scheme like scoping for functions where,
(defn test1 []
(defn test2 [] (+ 1 1))
(= (test2) 2))
would generate:
var test1 = function () {
var test2 = function () { return 1 + 1; };
return test2() == 2;
};
This effectively would hide `test2' from the toplevel, but this isn't
the behavior of `defn' as I discovered. So, by dropping the leading
`var' in the generated Javascript, I could make all the inner
functions exposed at the top level as well. I believe there's no
scoping semantics difference between the `x = function () {...}' and
`function x () {...}' forms, unless `x' is declared somewhere in the
scope as a local var. Of course, the scoping semantics completely
change with the explicit introduction of `var x = function () {...}'.
> * "if { ... } else { ...} break;" is probably missing a semicolon
> before "break". Don't trust JS' implicit semicolon-adding ;-)
You're absolutely right. I'll add a test case and fix that today.
> * The whole function body is being wrapped in a "return function()
> { ...}()". Is this done in order to support implicit return? My guess
> is that deeply nesting such constructs could become quite performance-
> heavy due to the many additional function calls.
You're probably right. As I worked on the let/loop forms I suspected
they were probably going to have performance issues in the long run,
but I really really wanted to have consistent scoping rules. I traded
off the performance issue in the expectation that with the race to
build the fastest Javascript JIT compiler, Google, Mozilla, or Apple
will eventually solve these crazy performance gotchas in Javascript.
> * Mozilla's JS 1.7 supports a let statement[1] with lexical scoping,
> though implementation support outside of Firefox is scarce. Depending
> on your target audience and performance requirements it could be
> worthwhile to implement this as an optimization instead of using the
> "function(){...}()" trick, but only if allowed by some flag,
> like :features #{:let} or similar.
That's an interesting idea, although I'm not too keen on specializing
for any one browser. The other problem is I don't see any reasonable
way of providing the alternates from a web server without some form of
user-agent sniffing.
>
> I'm going to take a deeper look into this once I have the time.
>
> [1]https://developer.mozilla.org/en/New_in_JavaScript_1.7#Block_scope_wi...
>
> Daniel
--
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
