| commit | ea53a7f796a6e9e749987def9291290258d605b2 | [log] [tgz] |
|---|---|---|
| author | Peter von der Ahé <ahe@google.com> | Thu Jun 16 14:26:07 2016 |
| committer | Peter von der Ahé <ahe@google.com> | Thu Jun 16 14:26:07 2016 |
| tree | f9fa38fab9d06163ff28ebaf824e7a12d89c5301 | |
| parent | 3a67cd4e65cf99a23ed7a466e6b6f06bc9893a00 [diff] |
Reduce dependencies on analyzer.
Dart Kernel is a small high-level language derived from Dart. It is designed for use as an intermediate format for whole-program analysis and transformations, and as a frontend for codegen and execution backends.
The kernel language has in-memory representations in Dart and C++, and can be serialized as binary or text.
Both the kernel language and its implementations are very early in development.
This package contains the Dart part of the implementation and contains:
Planned or work-in-progress:
Run bin/dartk.dart from the command-line to convert between .dart files and the serialized binary and textual formats.
dartk expects the .bart extension for files in the binary format. The textual format has no preferred extension right now.
Example commands:
dartk foo.dart # print text IR for foo.dart dartk foo.dart -ofoo.bart # write binary IR for foo.dart to foo.bart dartk foo.bart # print text IR for binary file foo.bart
Pass the --link or -l flag to link all transitive dependencies into one file:
dartk myapp.dart -ppackages -l -omyapp.bart # Bundle everything. dartk myapp.bart # Print it back out in a (very, very long) textual format.
See ast.dart for the in-memory IR, or binary.md for a description of the binary format. For now, the textual format is very ad-hoc and cannot be parsed back in.
Kernel distinguishes between library files and program files.
Program files are self-contained and cannot reference anything outside the file. Library files contain exactly one library and can import other libraries by a URI equivalent to how imports work in a .dart file.
Library files are a provisional concept and should not be used for anything serious yet, but can be used for quick experiments, like measuring the binary file size on a per-library basis.
The current frontend based on the analyzer is quite slow, probably because it computes a lot more information than we need. This frontend is temporary. The plan is to get a fast frontend before kernel is used for real.