OLD | NEW |
---|---|
1 dev_compiler | 1 dev_compiler |
2 ============ | 2 ============ |
3 | 3 |
4 [](https:/ /travis-ci.org/dart-lang/sdk) | 4 [](https:/ /travis-ci.org/dart-lang/sdk) |
5 [](https://coveralls.io/r/dart-lang/sdk) | |
6 | 5 |
7 The Dart Dev Compiler (DDC) is an **experimental** development tool and transpil er. It is at a very early stage today. Its aims include the following: | 6 The Dart Dev Compiler (DDC) is a fast, modular compiler that generates modern Ja vaScript (EcmaScript 6). Its primary use today to support fast, iterative devel opment of Dart for web applications on Chrome and other modern browers. |
Bob Nystrom
2017/06/05 21:50:51
"today to" -> "today is to".
I don't think "Dart
vsm
2017/06/05 22:03:21
Done.
| |
8 | 7 |
9 - A static checker based on stricter-than-standard-Dart type rules. | 8 Most users will use DDC via [pub](https://webdev.dartlang.org/tools/pub/pub-serv e). It will be supported by pub starting with the Dart 1.24 release. |
Bob Nystrom
2017/06/05 21:50:51
"will be" -> "is".
vsm
2017/06/05 22:03:21
Done.
| |
10 - A modular Dart-to-ES6 transpiler for Dart programs that statically check. | |
11 | 9 |
12 DDC attempts to map to idiomatic EcmaScript 6 (ES6) as cleanly as possible. To do this while cohering to Dart semantics, DDC relies heavily on static type info rmation, static checking, and runtime assertions. | 10 # Soundness and Restrictions |
13 | 11 |
14 DDC is intended to support a very [large subset](https://github.com/dart-lang/sd k/blob/master/pkg/dev_compiler/STRONG_MODE.md) of Dart. If a program does not s tatically check, DDC will not result in valid generated code. Our goal is that a program execution (of a valid program) that runs without triggering runtime as sertions should run the same on other Dart platforms under checked mode or produ ction mode. | 12 DDC is built upon Dart's new [strong mode](STRONG_MODE.md) type system. It only compiles programs that statically type check (i.e., no strong mode errors). It leverages static type checking to generate simpler, readable, and more idiomati c code with fewer runtime checks. In general, DDC is able to provide stronger t ype guarantees - i.e., *soundness* - than traditional Dart checked mode with sig nificantly fewer runtime checks. |
15 | 13 |
16 DDC does support untyped Dart code, but it will typically result in less readabl e and less efficient ES6 output. | 14 With strong mode, DDC is stricter than traditional Dart production mode or check ed mode. Running existing Dart code on DDC will generally require fixing both s tatic and runtime type errors. |
17 | 15 |
18 DDC has the following project goals: | 16 For example, although the following snippet will run in production or checked mo de, it will fail to compile with DDC: |
19 | 17 |
20 - Effective static checking and error detection. | 18 ```dart |
21 - A debugging solution for all modern browsers. | 19 var list = ["hello", "world"]; // Inferred as List<String> in strong mode |
22 - Readable output. | 20 List<int> list2 = list; // Static type error: incompatible types |
Bob Nystrom
2017/06/05 21:50:50
Nit: Indentation isn't needed here.
vsm
2017/06/05 22:03:21
Done.
| |
23 - Fast, modular compilation of Dart code. | 21 ``` |
24 - Easy use of generated code from JavaScript. | |
25 | 22 |
26 DDC is still in a very early stage as highlighted by our choice of ES6. ES6 its elf is in active development across all modern browsers, but at various stages o f support: | 23 On the other hand, the following snippet - which tries to mask the type error vi a casts - will compile with DDC, but fail with a runtime type error. |
24 | |
25 ```dart | |
26 var list = ["hello", "world"]; | |
27 List<Object> list2 = list; // Generics are covariant. No runtime check requi red. | |
28 List<int> list3 = list2; // Implicit runtime downcast triggers error | |
Bob Nystrom
2017/06/05 21:50:51
Nit: Add "." at end of comment.
vsm
2017/06/05 22:03:21
Done.
| |
29 ``` | |
30 | |
31 See the [strong mode documentation](STRONG_MODE.md) for more details. | |
32 | |
33 # Modularity | |
34 | |
35 DDC provides fast, incremental compilation based on standard JavaScript modules. Unlike Dart2JS, DDC does not require an entire Dart application. Instead, it operates modularly: it compiles a set of Dart files into a JavaScript module. A DDC compilation step requires a set of input Dart files and a set of *summaries * of dependencies. It performs modular type checking as part of this compilatio n step, and, if the input type checks, it generates a JavaScript module (e.g., [ *ES6*](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Stateme nts/import), [*AMD*](https://github.com/amdjs/amdjs-api/blob/master/AMD.md), or [*CommonJS*](https://nodejs.org/docs/latest/api/modules.html). The browser (i.e ., the JavaScript runtime) loads and links the generated modules when running th e application. | |
36 During development, a compilation step only needs to be rerun if the Dart files or summaries it relies upon change. For most changes, only a very small part of your code will require recompilation. Morever, modules that are unchanged can be cached in the browser. | |
37 | |
38 Most users will invoke DDC indirectly via [pub](https://webdev.dartlang.org/tool s/pub/pub-serve). Pub will compute module structure and build steps automatical ly and invoke DDC accordingly. Pub configures DDC to use AMD modules and uses t he standard [AMD `require.js` loader](http://requirejs.org/) to bootstrap and lo ad the application. | |
Bob Nystrom
2017/06/05 21:50:51
"will invoke" -> "invoke".
"will compute" -> "com
vsm
2017/06/05 22:03:21
Done.
| |
39 | |
40 More advanced users may want to configure or invoke DDC directly. In general, t he mapping of Dart files to JS modules is flexible. The key requirement is that module dependences (i.e., `require` in AMD or CommonJS or `import` in ES6) must be acyclic. In practice, this means that individual Dart libraries cannot each be mapped to a corresponding JS module (as Dart imports can be cyclic). See th e [usage document](USAGE.md) for more details. | |
Bob Nystrom
2017/06/05 21:50:51
Maybe "can be" -> "can be and often are".
vsm
2017/06/05 22:03:21
Done.
| |
41 | |
42 # EcmaScript 6 | |
43 | |
44 DDC attempts to map Dart to idiomatic EcmaScript 6 (ES6) as cleanly as possible, and it relies heavily on static typing to do this. In general, where Dart conc epts map directly to ES6, DDC will generate code accordingly. For example, Dart classes are mapped to ES6 classes, Dart fields to ES6 properties, Dart getters/ setters to ES6 getters/setters, Dart methods to ES6 methods, and so on. In most cases, names will be preserved and calling conventions will be natural JavaScri pt ones. | |
Bob Nystrom
2017/06/05 21:50:51
"will be" -> "are".
Bob Nystrom
2017/06/05 21:50:51
"will generate" -> "generates".
vsm
2017/06/05 22:03:21
Done.
vsm
2017/06/05 22:03:21
Done.
| |
45 | |
46 There are some import caveats where Dart concepts do not map directly: | |
47 | |
48 - *Libraries*. Multiple Dart libraries are mapped to a single JS module. Each library appears as a first class object in the generated JS module, with its top -level symbols as members. We currently use a heuristic (based upon file paths) to ensure unique naming of generated library objects. | |
49 - *Generics*. Dart generics are *reified*, i.e., they are preserved at runtime. Generic classes are mapped to factories that, given one or more type parameter s, return an actual ES6 class (e.g., `HashMap$(core.String, core.int)` produces a class that represents a HashMap from strings to ints). Similarly, generic met hods are mapped to factories that, given one or more type parameters, return a m ethod. | |
50 - *Dynamic*. DDC supports dynamically typed code (i.e., Dart's `dynamic` type), but it will typically generate less readable and less efficient ES6 output as m any type checks must be deferred to runtime. All dynamic operations are invoked via runtime helper code. | |
51 - *Constructors*. Dart supports multiple, named constructors for a given class with a different initialization order for fields. In general, these are mapped to static methods on the generated ES6 class. | |
52 - *Private members*. Dart maps private members (e.g., private fields or methods ) to ES6 symbols. For example, `a._x` may map to `a[_x]` where `_x` is a symbol only defined in the scope of the generated library. | |
53 - *Scoping*. Dart scoping rules and reserved words are slightly different than JavaScript. While we try to preserve names wherever possible, in certain cases, we may be required to rename. | |
Bob Nystrom
2017/06/05 21:50:51
"may be" -> "are".
vsm
2017/06/05 22:03:21
Done.
| |
54 | |
55 In general, the current conventions (i.e., the Application Binary Interface or A BI in compiler terminology) should not be considered stable. We reserve the rig ht to change these in the future. | |
56 | |
57 # Browser support | |
58 | |
59 DDC currently supports Chrome stable (though users have had success running on F ireFox and Safari). In the near future, we expect to run all common modern brow sers that support ES6. ES6 itself is in active development across all modern br owsers, but at advanced stages of support: | |
Bob Nystrom
2017/06/05 21:50:50
"run all" -> "target all".
vsm
2017/06/05 22:03:21
Done.
| |
60 | |
27 [kangax.github.io/compat-table/es6](https://kangax.github.io/compat-table/es6/). | 61 [kangax.github.io/compat-table/es6](https://kangax.github.io/compat-table/es6/). |
28 | |
29 We are targeting the subset of ES6 supported in Chrome. | |
30 | |
31 To try out DDC and/or give feedback, please read our [usage](https://github.com/ dart-lang/sdk/blob/master/pkg/dev_compiler/USAGE.md) page. | |
OLD | NEW |