4 ms·

Clojure supports namespaces and namespace-public/namespace-private functions. It's relatively easy to stuff every namespace-public function into a hash of its

Clojure supports namespaces and namespace-public/namespace-private functions. It's relatively easy to stuff every namespace-public function into a hash of its full name -> mangled name, thus both making resolving trivial and preventing supercompilation from stripping functions you might need.

takeoutweight 15y ago
You've described exactly why eval is antithetical to dead code elimination: you must defensively include absolutely every public function in every referenced library, because you do not know beforehand which functions an arbitrary evalled form will call.
- guard-of-terra 15y ago
  Well, we can drop all namespaces other than those used or explicitly specified. It's all solveable.
lukev 15y ago
This would prevent supercompilation from stripping any functions, because you never know what a future eval would need. This is bad because, without supercompilation, ClojureScript and its dependencies are quite large. Would you rather your compiled .js file be 500kb or 5kb? That's the difference we're talking about, here. Sure, ClojureScript might not be a "full lisp" without eval, but pragmatically, having tiny .js files is a much bigger win.
- JoelMcCracken 15y ago
  This level of eval that we're discussing is only really important for developers. Give your super users a bookmarklet which downloads the huge lib, and pops a repl up on the page. Everyone else gets to use the library as usual. Put the standard lib on a public CDN, and this would be okay.
  - lukev 15y ago
    And I have no doubt that's how it would be done, except that it turns out eval isn't actually necessary for a browser interactive REPL, which is pretty much all that developers need.
    - JoelMcCracken 15y ago
      Problem is that the js compilation happens on the server, then. Not all who may desire an interactive REPL are necessarily trusted.
      - markokocic 15y ago
        You can always use applet to compile on the client, you don't have to compile on the server. It would be easy to create reply like this.
        JoelMcCracken 15y ago
        Didn't even think of that. Good point.

takeoutweight 15y ago

You've described exactly why eval is antithetical to dead code elimination: you must defensively include absolutely every public function in every referenced library, because you do not know beforehand which functions an arbitrary evalled form will call.

guard-of-terra 15y ago
Well, we can drop all namespaces other than those used or explicitly specified. It's all solveable.

lukev 15y ago

This would prevent supercompilation from stripping any functions, because you never know what a future eval would need. This is bad because, without supercompilation, ClojureScript and its dependencies are quite large. Would you rather your compiled .js file be 500kb or 5kb? That's the difference we're talking about, here. Sure, ClojureScript might not be a "full lisp" without eval, but pragmatically, having tiny .js files is a much bigger win.

JoelMcCracken 15y ago
This level of eval that we're discussing is only really important for developers. Give your super users a bookmarklet which downloads the huge lib, and pops a repl up on the page. Everyone else gets to use the library as usual. Put the standard lib on a public CDN, and this would be okay.
- lukev 15y ago
  And I have no doubt that's how it would be done, except that it turns out eval isn't actually necessary for a browser interactive REPL, which is pretty much all that developers need.
  - JoelMcCracken 15y ago
    Problem is that the js compilation happens on the server, then. Not all who may desire an interactive REPL are necessarily trusted.
    - markokocic 15y ago
      You can always use applet to compile on the client, you don't have to compile on the server. It would be easy to create reply like this.
      - JoelMcCracken 15y ago
        Didn't even think of that. Good point.