Write all of the runtime in Dart.

[ochafik]

This would help with:

• Support for different module systems (integrate with existing JS module systems #284)
• Closure Compiler output (with fully-annotated runtime primitives)

Note that this would imply changing the signature of a couple of vararg functions (dart.mixin, dart.fn...).

There are a couple of files that need translation as they produce modules:

• rtti
• types
• classes
• errors
• generators
• operations
• dart_runtime

The following helper file needs to be converted to a module:

• dart_utils.js (d91add0)

Then the following file is used to support the current module system, so we might not want to translate them:

• dart_library

[ochafik]

Started experimenting in branch passthrough-js-interop.

[jmesserly]

yeah, the methods that take rest arguments are a problem. @jacob314 @vsmenon any thoughts on how we can encode it in such a way DDC understands?

Other than that, do we need anything other than the existing "JS" builtin? dart2js implements the SDK with it, so it should be pretty powerful.

edit: and we also have Jacob's interop which allows "direct" calls to JS members. So we might be able to use that as well.

[jmesserly]

oh, we also need a way to get DDC to stop emitting type assertions around JS builtin expressions. Either fixing how we parse the type strings, or just trusting them and allow it to be assigned to any type.

[ochafik]

Regarding rest params, seems like an ad-hoc annotation such as @varargs could do the trick.

Note that dart_runtime/* modules might need to be relocated under dart/* if they're generated from the sdk input, as there is quite a bit of dart: scheme-specific logic in the compiler (and dart_runtime is not a valid scheme as it contains an underscore).

That is, for instance, dart_runtime.js currently defines a dart_runtime/dart module, but we might want the new equivalent _dart_runtime.dart to define a dart._dart_runtime library instead.

Regarding what to start with:

• It's unclear if any file is easier to translate before the others, as there's quite a bit of interdependence
• We can adopt rest parameters in our .js helpers, which will make the translation slightly easier.

(side-note: JS('', '...') can be used to wrap arbitrary payload without type assertions, and its parsing limitations - no ES6 support - seem straightforward to work around)

[jmesserly]

@ochafik -- do you mind moving your checklist into the first message, or do you mind if I do it? GitHub has some special UI magic for checklists, but it only seems to kick in if they're in the initial bug report comment :)

[jacob314]

Some support for rest parameters would be very helpful for JS interop in general. This is one of the of edge cases we have to hack around today.

[ochafik]

@jacob314 I'm toying with a @varargs annotation for params + varargs(args) -> ...args argument transform in branch runtime-varargs, WDYT?

[jacob314]

I'm open to adding '''@VarArgs''' to package:js with the other js interop specific annotations.

[ochafik]

@jacob314 Cool! Filed dart-lang/sdk#24623 to track :-)

[jmesserly]

🎉