3 ms·

I'm not terribly familiar with the details of Dart. How does it know that something can never be null? Maybe an external caller sends null to a method not exp

I'm not terribly familiar with the details of Dart. How does it know that something can never be null? Maybe an external caller sends null to a method not expecting it. Or, can you not call Dart compiled code from JS?

pohl 14y ago
I don't know Dart (yet...I am familiar with its spiritual ancestor GWT) but if it's possible to expose functions to javascript, couldn't the compiler reason about those interfaces, treating incoming values as "dirty" (potentially null), and omit null checks if no external functions are exposed? For example, GWT lightly-abuses the 'native' keyword in Java to mark a method as using the FFI to raw javascript. That's a piece of information the compiler can leverage.
munificent 14y ago
> How does it know that something can never be null? It can see every place it gets assigned. If it's never assigned from something that can be null, it can't be null. Of course, that requires global inference to determine the possible types that the RHS can be. dart2js does that with increasing sophistication. > Maybe an external caller sends null to a method not expecting it. dart2js is a whole program compiler so it can make closed world assumptions like this. At the point that it's compiling, there are no "external" callers. It can see every callsite in the entire program. > Or, can you not call Dart compiled code from JS? Yes, Dart does have a JS interop story[1]. We're still working on it, but, by design, it's not as seamless as say CoffeeScript. It's an actual interop process and not just "it's all JS so it can all call each other". I think that helps dart2js control the places where unknown values can leak in from JS. [1]: http://www.dartlang.org/articles/js-dart-interop/ http://www.dartlang.org/articles/js-dart-interop/
- lmkg 14y ago
  Is this a limitation of Dart in general, or just the Dart2JS framework? Doing whole-program analysis seems like it would restrict your deployment methods, right? It's fairly common in the JS world to be calling into libraries that are split into separate files and hosted on external servers. Something like jQuery you do it for the load times, something like Google Analytics you do it so that Google can push updates without you needing to redeploy your script. There are also possible use cases with lazy-loading libraries for load times, or only loading scripts on certain pages. Does the whole-program compiling approach mean that I would have to import whole libraries into my own project in order to use them, and that I can only deploy single script files? How does the whole-program approach interact with event handlers embedded in HTML, which it would not have visibility into? I would expect that some of these restrictions could maybe be eased in a native-Dart client. But given that for the foreseeable future most Dart projects will have to target non-Dart-enabled clients, in practical terms Dart as a whole will have to be shackled to any limitations in Dart2JS. I'm curious what your thoughts on this are and if you have any plans to address it.
  - floitsch 14y ago
    This is a property of dart2js. (I wouldn't call it a limitation nor a feature). Dart2js takes your whole program and compiles it to JavaScript. Dart2js needs to see all the libraries that are used. It performs tree-shaking to remove unused parts and then compiles the rest to JavaScript. By default dart2js produces one big JavaScript file, but it can cut your program on library boundaries that can be loaded lazily. This is still work in progress (only allows to split into 2 files so far) but looks promising. The lazy loading needs to be done by the user before parts of the lazy library are used. I don't see how event-handlers change the game. The html-library is a library like any other.
    - lnanek2 14y ago
      There are a lot JS frameworks nowadays where there is no HTML, really, just a little something to trigger the script. Everything else is JavaScript generated and inserted HTML. I don't see how this could handle something like a new anchor being added with an javascript: href, or even just the eval command, for example. Doesn't seem smart to break JS compatibility like this if the language wants to win any mind share.
      - sethladd 14y ago
        [disclaimer, I work on the Dart team] While I do believe our Dart/JavaScript interop story will continue to be refined, I do want to point out that the days of javascript: URLs and eval are nearly over. The Web is getting a stronger security model through CSP [1] (content security policy). New restrictions put in place by CSP include turning off eval, new Function, inline JavaScript, and more. This is a very good thing, because it reduces the attack vectors for XSS and more. [1] http://www.html5rocks.com/en/tutorials/security/content-security-policy/ http://www.html5rocks.com/en/tutorials/security/content-secu...
  - munificent 14y ago
    > It's fairly common in the JS world to be calling into libraries that are split into separate files and hosted on external servers. Sometimes, but I think it's actually more common to do the opposite: minimize the delay by concatenating and minified all of your JS files into one big blog. That way there's only one network roundtrip. dart2js follows that path. > something like Google Analytics you do it so that Google can push updates without you needing to redeploy your script For stuff like this where you just have multiple completely independent scripts, you can just have separate <script> tags. > How does the whole-program approach interact with event handlers embedded in HTML, which it would not have visibility into? We actually do have visibility there. Dart has its own DOM library and dart2js has pretty deep insight into how to interact with the DOM.

pohl 14y ago

I don't know Dart (yet...I am familiar with its spiritual ancestor GWT) but if it's possible to expose functions to javascript, couldn't the compiler reason about those interfaces, treating incoming values as "dirty" (potentially null), and omit null checks if no external functions are exposed? For example, GWT lightly-abuses the 'native' keyword in Java to mark a method as using the FFI to raw javascript. That's a piece of information the compiler can leverage.

munificent 14y ago

> How does it know that something can never be null? It can see every place it gets assigned. If it's never assigned from something that can be null, it can't be null. Of course, that requires global inference to determine the possible types that the RHS can be. dart2js does that with increasing sophistication. > Maybe an external caller sends null to a method not expecting it. dart2js is a whole program compiler so it can make closed world assumptions like this. At the point that it's compiling, there are no "external" callers. It can see every callsite in the entire program. > Or, can you not call Dart compiled code from JS? Yes, Dart does have a JS interop story[1]. We're still working on it, but, by design, it's not as seamless as say CoffeeScript. It's an actual interop process and not just "it's all JS so it can all call each other". I think that helps dart2js control the places where unknown values can leak in from JS. [1]: http://www.dartlang.org/articles/js-dart-interop/ http://www.dartlang.org/articles/js-dart-interop/

lmkg 14y ago
Is this a limitation of Dart in general, or just the Dart2JS framework? Doing whole-program analysis seems like it would restrict your deployment methods, right? It's fairly common in the JS world to be calling into libraries that are split into separate files and hosted on external servers. Something like jQuery you do it for the load times, something like Google Analytics you do it so that Google can push updates without you needing to redeploy your script. There are also possible use cases with lazy-loading libraries for load times, or only loading scripts on certain pages. Does the whole-program compiling approach mean that I would have to import whole libraries into my own project in order to use them, and that I can only deploy single script files? How does the whole-program approach interact with event handlers embedded in HTML, which it would not have visibility into? I would expect that some of these restrictions could maybe be eased in a native-Dart client. But given that for the foreseeable future most Dart projects will have to target non-Dart-enabled clients, in practical terms Dart as a whole will have to be shackled to any limitations in Dart2JS. I'm curious what your thoughts on this are and if you have any plans to address it.
- floitsch 14y ago
  This is a property of dart2js. (I wouldn't call it a limitation nor a feature). Dart2js takes your whole program and compiles it to JavaScript. Dart2js needs to see all the libraries that are used. It performs tree-shaking to remove unused parts and then compiles the rest to JavaScript. By default dart2js produces one big JavaScript file, but it can cut your program on library boundaries that can be loaded lazily. This is still work in progress (only allows to split into 2 files so far) but looks promising. The lazy loading needs to be done by the user before parts of the lazy library are used. I don't see how event-handlers change the game. The html-library is a library like any other.
  - lnanek2 14y ago
    There are a lot JS frameworks nowadays where there is no HTML, really, just a little something to trigger the script. Everything else is JavaScript generated and inserted HTML. I don't see how this could handle something like a new anchor being added with an javascript: href, or even just the eval command, for example. Doesn't seem smart to break JS compatibility like this if the language wants to win any mind share.
    - sethladd 14y ago
      [disclaimer, I work on the Dart team] While I do believe our Dart/JavaScript interop story will continue to be refined, I do want to point out that the days of javascript: URLs and eval are nearly over. The Web is getting a stronger security model through CSP [1] (content security policy). New restrictions put in place by CSP include turning off eval, new Function, inline JavaScript, and more. This is a very good thing, because it reduces the attack vectors for XSS and more. [1] http://www.html5rocks.com/en/tutorials/security/content-security-policy/ http://www.html5rocks.com/en/tutorials/security/content-secu...
- munificent 14y ago
  > It's fairly common in the JS world to be calling into libraries that are split into separate files and hosted on external servers. Sometimes, but I think it's actually more common to do the opposite: minimize the delay by concatenating and minified all of your JS files into one big blog. That way there's only one network roundtrip. dart2js follows that path. > something like Google Analytics you do it so that Google can push updates without you needing to redeploy your script For stuff like this where you just have multiple completely independent scripts, you can just have separate <script> tags. > How does the whole-program approach interact with event handlers embedded in HTML, which it would not have visibility into? We actually do have visibility there. Dart has its own DOM library and dart2js has pretty deep insight into how to interact with the DOM.