[dart-misc] Kernel IR

[kc]

This looked interesting:

https://github.com/dart-lang/kernel

Will this IR be public facing with a standard format - to interface to the
runtime - or will the input remain only source code.

K.

['Vyacheslav Egorov' via Dart Misc]

Right now Kernel is an (experimental) implementation detail.

We don't have any plans to share beyond what was said in the presentation.

On Tue, Nov 1, 2016 at 3:08 PM kc <***@gmail.com> wrote:

This looked interesting:

https://github.com/dart-lang/kernel

http://youtu.be/lqE4u8s8Iik

Will this IR be public facing with a standard format - to interface to the
runtime - or will the input remain only source code.

K.
--
For other discussions, see https://groups.google.com/a/dartlang.org/

For HOWTO questions, visit http://stackoverflow.com/tags/dart

To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to misc+***@dartlang.org.
--
// Vyacheslav Egorov

[kc]

Post by 'Vyacheslav Egorov' via Dart Misc
Right now Kernel is an (experimental) implementation detail.

In some respects the kernel lang textual representation is superior to
actual dart lang:

library;
import self as self;
import "dart:core" as core;


class Callable extends core::Object {
constructor •() → void
: super core::Object::•()
;
method call(dynamic x) → dynamic {
return "string";
}
}


1) type on rhs of method/function with an arrow (maybe superior to rhs ':'
syntax).
2) modules distinguished from objects with '::' instead of '.'
3) 'constructor' instead of class name

Seems 'familiar' and has benefits re parsing, tooling, eyeballing and
keyboard input.

Other explicit parts like 'method' are obviously overkill as can be easily
inferred from the context.

Post by 'Vyacheslav Egorov' via Dart Misc
We don't have any plans to share beyond what was said in the presentation.

Well at some point this project should share. With more feedback from
outside Google this experiment could avoid the fate of Dart 1.x, CDE and
Dartino.

The Dart 1.x runtime was too much of a blackbox. Flutter is all about a
transparent layered architecture - the Dart runtime should share this
philosophy.

K.

[Filipe Morgado]

I'm counting the time until they deprecate running Dart from source in the
VM.

Maybe Dart 2.x will just run alongside Dart 1.x, seamlessly interoperating,
since they both compile to the same IR.
No more worrying about breaking changes.
(Would still have to deal with another file extension, or header?)

This unified compilation strategy should have come a lot sooner.

[DoHyung Kim]

I don't want to see a separate compilation step to the kernel IR sneaks in
my development cycles. I have been hindered by such a step in my whole
career with JVM. ;)

Anyway, I agree with you that the kernel IR can ease transition to Dart 2
if it's not source-level compatible with Dart 1.x. I remember there was a
mention from a member of the Dart team that Dart 2 would break
compatibility but such incompatibility is most likely in syntax only.

DH

Post by Filipe Morgado
I'm counting the time until they deprecate running Dart from source in the
VM.
Maybe Dart 2.x will just run alongside Dart 1.x, seamlessly
interoperating, since they both compile to the same IR.
No more worrying about breaking changes.
(Would still have to deal with another file extension, or header?)
This unified compilation strategy should have come a lot sooner.

[Filipe Morgado]

Post by DoHyung Kim
I don't want to see a separate compilation step to the kernel IR sneaks in
my development cycles. I have been hindered by such a step in my whole
career with JVM. ;)

I agree ... and loading from source is not going anywhere ... we just got
hot reloading.

But maybe it wouldn't be that bad if Bazel
<https://github.com/bazelbuild/bazel> delivers.
It seems (I may be wrong) the default workflow for web apps is soon gonna
be DDC/Bazel and ditch Dartium, which is a pain to roll forward.

It seems the VM is now very modular.
It includes JITs, AoT compilers, DBC interpreter, and loads from source,
Kernel IR or snapshots.

There could be many VM builds for specific workflows.
In development, the VM uses JIT (or DBC for iOS) and loads code from source.
For mobile release builds, it compiles them with a VM for AoT that loads
from source, and runs them in a VM stripped of all the above.
(Or maybe there's no VM at all, just a runtime lib).
For server builds, it only includes JIT and loads only from Kernel IR (or
snapshots).

[DoHyung Kim]

If Kernel IR (preferably in its binary encoding) is treated like the
current snapshot, which is still an implementation detail and may be
incompatible across releases, then what you envision might make sense. The
idea of different flavors of Dart VM looks interesting to me, too.

DH

Post by Filipe Morgado

Post by DoHyung Kim
I don't want to see a separate compilation step to the kernel IR sneaks
in my development cycles. I have been hindered by such a step in my whole
career with JVM. ;)

I agree ... and loading from source is not going anywhere ... we just got
hot reloading.
But maybe it wouldn't be that bad if Bazel
<https://github.com/bazelbuild/bazel> delivers.
It seems (I may be wrong) the default workflow for web apps is soon gonna
be DDC/Bazel and ditch Dartium, which is a pain to roll forward.
It seems the VM is now very modular.
It includes JITs, AoT compilers, DBC interpreter, and loads from source,
Kernel IR or snapshots.
There could be many VM builds for specific workflows.
In development, the VM uses JIT (or DBC for iOS) and loads code from source.
For mobile release builds, it compiles them with a VM for AoT that loads
from source, and runs them in a VM stripped of all the above.
(Or maybe there's no VM at all, just a runtime lib).
For server builds, it only includes JIT and loads only from Kernel IR (or
snapshots).

['Kevin Millikin' via Dart Misc]

I work on the Dart Kernel team and I can say a little bit more about what
we're trying to achieve with it.

We see Kernel as an intermediate format something like object files. It is
focused on ahead-of-time compilation as done in dart2js, DDC, and the Dart
VM in AOT mode. It is designed to support separate compilation and
incremental recompilation.

We do view it as an implementation detail, which means you might have to
recompile your app for a new version of the SDK. For the time being, we
will allow ourselves to make changes to the language and binary format that
are not backwards compatible. Eventually, Kernel itself will be part of
the SDK instead of a third party dependency. Obviously we'll want our
tooling to make everything easy and seamless.

The Kernel language is a simple high-level OO language with Dart semantics,
which means that it's not necessarily an attractive compilation target for
other languages --- that's not our goal.

We'll have more to say in the coming months, and we welcome community input!

Post by DoHyung Kim
If Kernel IR (preferably in its binary encoding) is treated like the
current snapshot, which is still an implementation detail and may be
incompatible across releases, then what you envision might make sense. The
idea of different flavors of Dart VM looks interesting to me, too.
DH
I don't want to see a separate compilation step to the kernel IR sneaks in
my development cycles. I have been hindered by such a step in my whole
career with JVM. ;)
I agree ... and loading from source is not going anywhere ... we just got
hot reloading.
But maybe it wouldn't be that bad if Bazel
<https://github.com/bazelbuild/bazel> delivers.
It seems (I may be wrong) the default workflow for web apps is soon gonna
be DDC/Bazel and ditch Dartium, which is a pain to roll forward.
It seems the VM is now very modular.
It includes JITs, AoT compilers, DBC interpreter, and loads from source,
Kernel IR or snapshots.
There could be many VM builds for specific workflows.
In development, the VM uses JIT (or DBC for iOS) and loads code from source.
For mobile release builds, it compiles them with a VM for AoT that loads
from source, and runs them in a VM stripped of all the above.
(Or maybe there's no VM at all, just a runtime lib).
For server builds, it only includes JIT and loads only from Kernel IR (or
snapshots).
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[DoHyung Kim]

Per the presentation at this dev summit, I assumed that it's just for
reducing efforts in evolving Dart as a language, serving as a low level
target language to which Dart proper is desugared. It's a little bit of
surprise to me that it's intended to be used more like object codes by
design.

BTW, is Kernel IR not relevant to JITC? I see no reason to make JITC a
special case here.

DH

Post by 'Kevin Millikin' via Dart Misc
I work on the Dart Kernel team and I can say a little bit more about what
we're trying to achieve with it.
We see Kernel as an intermediate format something like object files. It
is focused on ahead-of-time compilation as done in dart2js, DDC, and the
Dart VM in AOT mode. It is designed to support separate compilation and
incremental recompilation.
We do view it as an implementation detail, which means you might have to
recompile your app for a new version of the SDK. For the time being, we
will allow ourselves to make changes to the language and binary format that
are not backwards compatible. Eventually, Kernel itself will be part of
the SDK instead of a third party dependency. Obviously we'll want our
tooling to make everything easy and seamless.
The Kernel language is a simple high-level OO language with Dart
semantics, which means that it's not necessarily an attractive compilation
target for other languages --- that's not our goal.
We'll have more to say in the coming months, and we welcome community input!

Post by DoHyung Kim
If Kernel IR (preferably in its binary encoding) is treated like the
current snapshot, which is still an implementation detail and may be
incompatible across releases, then what you envision might make sense. The
idea of different flavors of Dart VM looks interesting to me, too.
DH

Post by Filipe Morgado

Post by DoHyung Kim
I don't want to see a separate compilation step to the kernel IR sneaks
in my development cycles. I have been hindered by such a step in my whole
career with JVM. ;)

I agree ... and loading from source is not going anywhere ... we just
got hot reloading.
But maybe it wouldn't be that bad if Bazel
<https://github.com/bazelbuild/bazel> delivers.
It seems (I may be wrong) the default workflow for web apps is soon
gonna be DDC/Bazel and ditch Dartium, which is a pain to roll forward.
It seems the VM is now very modular.
It includes JITs, AoT compilers, DBC interpreter, and loads from source,
Kernel IR or snapshots.
There could be many VM builds for specific workflows.
In development, the VM uses JIT (or DBC for iOS) and loads code from source.
For mobile release builds, it compiles them with a VM for AoT that loads
from source, and runs them in a VM stripped of all the above.
(Or maybe there's no VM at all, just a runtime lib).
For server builds, it only includes JIT and loads only from Kernel IR
(or snapshots).

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Benjamin Strauß]

Post by DoHyung Kim
BTW, is Kernel IR not relevant to JITC? I see no reason to make JITC a
special case here.

In JIT mode the dart-vm directly reads dart code, there is no intermediate
format.

[DoHyung Kim]

Why so? Isn't implementing lang features only once for all Dart impls one
of the rationales behind Kernel IR? Just curious.

Post by Benjamin Strauß

Post by DoHyung Kim
BTW, is Kernel IR not relevant to JITC? I see no reason to make JITC a
special case here.

In JIT mode the dart-vm directly reads dart code, there is no intermediate
format.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to a topic in the
Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
dartlang.org/d/topic/misc/9Q7EAfQ63uU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to

[Benjamin Strauß]

The dart-vm was originally intended to be included into chrome and on the
web there is no binary format (yet), you basically serve source code, thus
the vm needed to be able to process it directly.

Post by DoHyung Kim
Why so? Isn't implementing lang features only once for all Dart impls one
of the rationales behind Kernel IR? Just curious.

Post by Benjamin Strauß

Post by DoHyung Kim
BTW, is Kernel IR not relevant to JITC? I see no reason to make JITC a
special case here.

In JIT mode the dart-vm directly reads dart code, there is no
intermediate format.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to a topic in the
Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/dartlang.org/d/topic/misc/9Q7EAfQ63uU/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to

[DoHyung Kim]

Thank you for the clarification.
Then Dart VM may still leverage kernel IR internally? If not, I'm afraid
Dart VM JITC is left behind other impls in implementing new language
features.

BR, DH

Post by Benjamin Strauß
The dart-vm was originally intended to be included into chrome and on the
web there is no binary format (yet), you basically serve source code, thus
the vm needed to be able to process it directly.

Post by DoHyung Kim
Why so? Isn't implementing lang features only once for all Dart impls one
of the rationales behind Kernel IR? Just curious.

Post by Benjamin Strauß

Post by DoHyung Kim
BTW, is Kernel IR not relevant to JITC? I see no reason to make JITC a
special case here.

In JIT mode the dart-vm directly reads dart code, there is no
intermediate format.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
---
You received this message because you are subscribed to a topic in the
Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/da
rtlang.org/d/topic/misc/9Q7EAfQ63uU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to a topic in the
Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
dartlang.org/d/topic/misc/9Q7EAfQ63uU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to

['Kevin Millikin' via Dart Misc]

Post by DoHyung Kim
Thank you for the clarification.
Then Dart VM may still leverage kernel IR internally? If not, I'm afraid
Dart VM JITC is left behind other impls in implementing new language
features.

I was unclear. We have made the Dart VM's JIT compiler take Kernel binary
files as input, it is not a special case.

It's just that our short-term focus for Kernel itself is to do a bunch of
things that mainly will benefit AOT compilation

[Joe Blue]

thanks for the feedback Kevin. Sounds great ..

Post by 'Kevin Millikin' via Dart Misc
I work on the Dart Kernel team and I can say a little bit more about what
we're trying to achieve with it.
We see Kernel as an intermediate format something like object files. It
is focused on ahead-of-time compilation as done in dart2js, DDC, and the
Dart VM in AOT mode. It is designed to support separate compilation and
incremental recompilation.
We do view it as an implementation detail, which means you might have to
recompile your app for a new version of the SDK. For the time being, we
will allow ourselves to make changes to the language and binary format that
are not backwards compatible. Eventually, Kernel itself will be part of
the SDK instead of a third party dependency. Obviously we'll want our
tooling to make everything easy and seamless.
The Kernel language is a simple high-level OO language with Dart
semantics, which means that it's not necessarily an attractive compilation
target for other languages --- that's not our goal.
We'll have more to say in the coming months, and we welcome community input!

Post by DoHyung Kim
If Kernel IR (preferably in its binary encoding) is treated like the
current snapshot, which is still an implementation detail and may be
incompatible across releases, then what you envision might make sense. The
idea of different flavors of Dart VM looks interesting to me, too.
DH

Post by Filipe Morgado

Post by DoHyung Kim
I don't want to see a separate compilation step to the kernel IR sneaks
in my development cycles. I have been hindered by such a step in my whole
career with JVM. ;)

I agree ... and loading from source is not going anywhere ... we just
got hot reloading.
But maybe it wouldn't be that bad if Bazel
<https://github.com/bazelbuild/bazel> delivers.
It seems (I may be wrong) the default workflow for web apps is soon
gonna be DDC/Bazel and ditch Dartium, which is a pain to roll forward.
It seems the VM is now very modular.
It includes JITs, AoT compilers, DBC interpreter, and loads from source,
Kernel IR or snapshots.
There could be many VM builds for specific workflows.
In development, the VM uses JIT (or DBC for iOS) and loads code from source.
For mobile release builds, it compiles them with a VM for AoT that loads
from source, and runs them in a VM stripped of all the above.
(Or maybe there's no VM at all, just a runtime lib).
For server builds, it only includes JIT and loads only from Kernel IR
(or snapshots).

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[DoHyung Kim]

I would prefer having more detailed information on the internal
implementation of Dart VM and transpilers. But I see no oddity in not
sharing more details on Kernel IR outside the Dart team. It's an
implementation detail, which can be changed whenever and however required
without affecting users. And anyway you can see the source codes involved
if you want to know more about it. I like Golang sharing much of its plans
on improving its compiler implementation, but Golang community has more
people outside Google involved in the compiler implementation. So I guess
documentations are much more relevant there. BTW, if the Dart team has any
internal documentations on such implementation issues, I would be happy to
see some of them shared with us outside Google.

BR, DH

Post by kc

Post by 'Vyacheslav Egorov' via Dart Misc
Right now Kernel is an (experimental) implementation detail.

In some respects the kernel lang textual representation is superior to
library;
import self as self;
import "dart:core" as core;
class Callable extends core::Object {
constructor •() → void
: super core::Object::•()
;
method call(dynamic x) → dynamic {
return "string";
}
}
1) type on rhs of method/function with an arrow (maybe superior to rhs ':'
syntax).
2) modules distinguished from objects with '::' instead of '.'
3) 'constructor' instead of class name
Seems 'familiar' and has benefits re parsing, tooling, eyeballing and
keyboard input.
Other explicit parts like 'method' are obviously overkill as can be easily
inferred from the context.

Post by 'Vyacheslav Egorov' via Dart Misc
We don't have any plans to share beyond what was said in the presentation.

Well at some point this project should share. With more feedback from
outside Google this experiment could avoid the fate of Dart 1.x, CDE and
Dartino.
The Dart 1.x runtime was too much of a blackbox. Flutter is all about a
transparent layered architecture - the Dart runtime should share this
philosophy.
K.