[dart-misc] Dart 2.0 and Swift 2.0

[kc]

Interesting comment re Swift:

Beyond its implementation, the developer-facing aspects of Swift do embody

a specific philosophy about software development. I’ve been writing
software professionally for 18 years, and I definitely have my own opinions
about language design. For example, I find any coding done in service of
the type system to be mostly wasted effort when writing high-level code
that controls things like which window appears when a certain button is
pressed or which data is fetched from or stored into a database.
Swift’s type inference alleviates some of this pain, but it doesn’t change
the inherent static typing of the language. The choice between static and
dynamic typing is not just based on the effects each approach has on
compiler implementation. It’s also—perhaps even primarily—a philosophical
choice about what constitutes “good code.”
Motivations aside, it’s the practical consequences of Swift’s design
philosophy that make it resilient to my complaints. I admire Swift’s
ambitious mission and I understand how essential each one of its features
is to achieving it.
The strongest arguments against Swift are ultimately questions about that
mission. Swift could be a much friendlier high-level language if it gave up
on being an “industrial-quality systems programming language.” On the other
side of the coin, Swift could be vastly simpler if it focused exclusively
on being just “a better C.” Few languages have even attempted to do what
Swift is doing. The degree of difficulty is high and self-imposed—in other
words, a typical Apple move.

http://arstechnica.com/apple/2014/10/os-x-10-10/23/

I like Swift but in some ways it has gone too low-level and lost some
dynamism. Dart 2.0 with a more 'high-level' application focus (especially
with Flutter) could move into this vacated niche.

Currently Dart (with Checked Mode) looks more 'static' than Swift.

K.

[Günter Zöchbauer]

I don't see much value in dynamism. Sometimes it's cumbersome to satisfy
the type checker but as an alternative you have to check everything in unit
tests which makes them breed like rabbits and are much more cumbersome to
maintain.
Static typing is a about tools being able to analyze my code and support me
with information about possible inconsistencies. I find this much more
convenient than writing unit tests or just hoping that I encountered all
problems during manual testing (which then is is more tinkering than
engineering).

Checked mode is a choice therefore I don't see how this is a criteria.
Don't use it if you don't like it.

Post by kc
Beyond its implementation, the developer-facing aspects of Swift do embody

a specific philosophy about software development. I’ve been writing
software professionally for 18 years, and I definitely have my own opinions
about language design. For example, I find any coding done in service of
the type system to be mostly wasted effort when writing high-level code
that controls things like which window appears when a certain button is
pressed or which data is fetched from or stored into a database.
Swift’s type inference alleviates some of this pain, but it doesn’t
change the inherent static typing of the language. The choice between
static and dynamic typing is not just based on the effects each approach
has on compiler implementation. It’s also—perhaps even primarily—a
philosophical choice about what constitutes “good code.”
Motivations aside, it’s the practical consequences of Swift’s design
philosophy that make it resilient to my complaints. I admire Swift’s
ambitious mission and I understand how essential each one of its features
is to achieving it.
The strongest arguments against Swift are ultimately questions about that
mission. Swift could be a much friendlier high-level language if it gave up
on being an “industrial-quality systems programming language.” On the other
side of the coin, Swift could be vastly simpler if it focused exclusively
on being just “a better C.” Few languages have even attempted to do what
Swift is doing. The degree of difficulty is high and self-imposed—in other
words, a typical Apple move.

http://arstechnica.com/apple/2014/10/os-x-10-10/23/
I like Swift but in some ways it has gone too low-level and lost some
dynamism. Dart 2.0 with a more 'high-level' application focus (especially
with Flutter) could move into this vacated niche.
Currently Dart (with Checked Mode) looks more 'static' than Swift.
K.

[kc]

Post by Günter Zöchbauer
I don't see much value in dynamism. Sometimes it's cumbersome to satisfy
the type checker but as an alternative you have to check everything in unit
tests which makes them breed like rabbits and are much more cumbersome to
maintain.
Static typing is a about tools being able to analyze my code and support
me with information about possible inconsistencies. I find this much more
convenient than writing unit tests or just hoping that I encountered all
problems during manual testing (which then is is more tinkering than
engineering).
Checked mode is a choice therefore I don't see how this is a criteria.
Don't use it if you don't like it.

The problem with Checked Mode is that it's a whole app on-off switch. Can't
be done per module/lib or dialled-up. Gilad (I think) prefers that approach
of static checks being an lang/AST rewrite rather than baked into the
runtime. Thus the static type checker can evolve independently of the
runtime.

K.

[Filipe Morgado]

Personally, I like static type systems. I just don't like having to write
types everywhere to get reasonable analysis.

I find any coding done in service of the type system to be mostly wasted
effort when writing high-level code

If a function takes a String argument, I wanna be sure it can only be
passed a String, not anything else, not even null (unless I specify it).
And Dart with static (sound) typing would be much easier to compile
natively (hello iOS).

I can't comment on how it is to work with Swift, but it does seems
interesting.
I do like Ceylon, but I'm not a fan of JVM environments.

Bob mentioned that, since initial design considerations had changed, they
could break the s*** out of the language and the platform.
He even mentioned that the DartVM could become a bytecode VM which runs
fully-annotated binary ASTs (independently of language changes).
WebAssembly showed good preliminary results on this concept.
I do hope it goes this way.

Flash was pretty good (still is for me) as some benchmarks show
<https://github.com/joelgwebber/bench2d>. We can even run C/C++ on it.
I don't think we can get this kind of performance with dynamic
languages (as in "not fully inferred").
Most code doesn't even need polymorphism, why not optimize it away?
Something to consider since we want to target mobile and IoT.

Well, my 2 cts. :P

[kc]

Post by Filipe Morgado
Personally, I like static type systems. I just don't like having to write
types everywhere to get reasonable analysis.

I find any coding done in service of the type system to be mostly wasted
effort when writing high-level code

If a function takes a String argument, I wanna be sure it can only be
passed a String, not anything else, not even null (unless I specify it).
And Dart with static (sound) typing would be much easier to compile
natively (hello iOS).
I can't comment on how it is to work with Swift, but it does seems
interesting.
I do like Ceylon, but I'm not a fan of JVM environments.
Bob mentioned that, since initial design considerations had changed, they
could break the s*** out of the language and the platform.
He even mentioned that the DartVM could become a bytecode VM which runs
fully-annotated binary ASTs (independently of language changes).
WebAssembly showed good preliminary results on this concept.
I do hope it goes this way.
Flash was pretty good (still is for me) as some benchmarks show
<https://github.com/joelgwebber/bench2d>. We can even run C/C++ on it.
I don't think we can get this kind of performance with dynamic
languages (as in "not fully inferred").
Most code doesn't even need polymorphism, why not optimize it away?
Something to consider since we want to target mobile and IoT.
Well, my 2 cts. :P

Right. There was a 'theory' to Dart 1.x and the VM - types are
documentation - so it will be interesting if the Dart team go in another
direction.

Value objects seem to be the missing middle between standard reference
objects and 'const' objects.

My question is with Value Objects and maybe privileging core numeric types
like 'double' could you get much of the perf benefits and keep some
flexibility.

Personally for numeric/algorithmic/money code I want max static type
checks. But for higher-level code the dynamic/simulation aspect of objects
works well.

K.

['Erik Ernst' via Dart Misc]

Post by kc

Post by Filipe Morgado
Personally, I like static type systems. I just don't like having to write
types everywhere to get reasonable analysis.

I find any coding done in service of the type system to be mostly wasted
effort when writing high-level code

If a function takes a String argument, I wanna be sure it can only be
passed a String, not anything else, not even null (unless I specify it).
And Dart with static (sound) typing would be much easier to compile
natively (hello iOS).
I can't comment on how it is to work with Swift, but it does seems
interesting.
I do like Ceylon, but I'm not a fan of JVM environments.
Bob mentioned that, since initial design considerations had changed, they
could break the s*** out of the language and the platform.
He even mentioned that the DartVM could become a bytecode VM which runs
fully-annotated binary ASTs (independently of language changes).
WebAssembly showed good preliminary results on this concept.
I do hope it goes this way.
Flash was pretty good (still is for me) as some benchmarks show
<https://github.com/joelgwebber/bench2d>. We can even run C/C++ on it.
I don't think we can get this kind of performance with dynamic
languages (as in "not fully inferred").
Most code doesn't even need polymorphism, why not optimize it away?
Something to consider since we want to target mobile and IoT.
Well, my 2 cts. :P

Right. There was a 'theory' to Dart 1.x and the VM - types are
documentation - so it will be interesting if the Dart team go in another
direction.

With checked mode there is an alternative theory: The heap is sound, i.e.,
every variable with a type annotation will refer to to an instance of a
class that implements the annotated type, or null. That's a lot stronger
than being mere 'documentation' (which may or may not be true).

If we get a slightly stronger rule for function type subtyping (it should
require covariant return types rather than just assignability) then this
ensures for fully annotated programs that every expression that performs a
lookup will succeed (or get a 'null doesn't have a ..' error), and the
looked-up member will be in the statically known set of candidates (if you
call `x.foo` then the type annotation on `x` will determine an exact
declaration d of `foo`, and the dynamically invoked one will be either d or
a declaration which is statically known to override d).

best regards,
--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

[Filipe Morgado]

On some benchmarks, Dart performs as well as Java.
But in practice, it seems we barely outperform JS.

I believe the DartVM only implements one kind of method dispatch: dynamic.

As I understand it, at every call site, a (slow) dynamic lookup is
performed on the receiver.
Once a type is encountered a sufficient number of times, the call site is
recompiled with an optimized path for that particular type.
If too many types are encountered, all optimizations are thrown away and
dynamic lookup is always used.

I believe as well that it is this way so the DartVM doesn't have to perform
complicated type inference and/or analysis and have fast startup times.
But we end up with type checks all over the place and, sometimes maybe,
slow optimization/deoptimization cycles.

With a sound static type system, I think we could have 3 types of method
dispatch:

- Direct. We know a given instance is of a particular type, it wasn't
extended nor mixed in.
We call the method directly and may even inline it (provided we know
it's not null, NNBD ftw).
I believe most calls fall in this category.
- vTable. We know the type implements a given interface. The type
provides a method table for that interface.
We call the method through one single indirection (provided we
efficiently get that table and the instance is not null, NNBD ftw).
I believe most polymorphic calls fall in this category.
- Dynamic. We don't know the exact type so the call site behaves as
currently implemented (and explained above).
With union types, I believe dynamism would be used very rarely, mostly
when dealing with external sources such as Json.

We should pay the price of dynamism and/or polymorphism only when we
actually need it.
I believe this is a strong argument for sound static types and fully
annotated/inferred/optimized Dart programs.

We could rival Java/.NET/native on performance, anytime.
(arithmetic is another matter).

Thoughts?

(These are a lot of uneducated beliefs and assumptions, feel free to
correct me).

['Erik Ernst' via Dart Misc]

I mentioned a criterion that suffices to ensure that every lookup goes to a
statically known declaration or a declaration which is statically known to
override it; that criterion is also known as 'message safety'. This is
exactly what it takes to make vTable invocation correct.

The interesting thing to note is that it is strictly more flexible than
traditional soundness, because it allows for assignability where
traditional soundness would require subtyping for all value transfer
operations (assignment, argument passing, returns).

Post by Filipe Morgado
On some benchmarks, Dart performs as well as Java.
But in practice, it seems we barely outperform JS.
I believe the DartVM only implements one kind of method dispatch: dynamic.
As I understand it, at every call site, a (slow) dynamic lookup is
performed on the receiver.
Once a type is encountered a sufficient number of times, the call site is
recompiled with an optimized path for that particular type.
If too many types are encountered, all optimizations are thrown away and
dynamic lookup is always used.
I believe as well that it is this way so the DartVM doesn't have to
perform complicated type inference and/or analysis and have fast startup
times.
But we end up with type checks all over the place and, sometimes maybe,
slow optimization/deoptimization cycles.
With a sound static type system, I think we could have 3 types of method
- Direct. We know a given instance is of a particular type, it wasn't
extended nor mixed in.
We call the method directly and may even inline it (provided we know
it's not null, NNBD ftw).
I believe most calls fall in this category.
- vTable. We know the type implements a given interface. The type
provides a method table for that interface.
We call the method through one single indirection (provided we
efficiently get that table and the instance is not null, NNBD ftw).
I believe most polymorphic calls fall in this category.
- Dynamic. We don't know the exact type so the call site behaves as
currently implemented (and explained above).
With union types, I believe dynamism would be used very rarely, mostly
when dealing with external sources such as Json.
We should pay the price of dynamism and/or polymorphism only when we
actually need it.
I believe this is a strong argument for sound static types and fully
annotated/inferred/optimized Dart programs.
We could rival Java/.NET/native on performance, anytime.
(arithmetic is another matter).
Thoughts?
(These are a lot of uneducated beliefs and assumptions, feel free to
correct me).
--
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
To unsubscribe from this group and stop receiving emails from it, send an

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

['Bob Nystrom' via Dart Misc]

Post by Filipe Morgado
As I understand it, at every call site, a (slow) dynamic lookup is
performed on the receiver.
Once a type is encountered a sufficient number of times, the call site is
recompiled with an optimized path for that particular type.

Pretty much, yes.

Post by Filipe Morgado
If too many types are encountered, all optimizations are thrown away and
dynamic lookup is always used.

Also true, though it's worth noting that this happens fairly rarely in
practice. Even in completely dynamically typed languages, any given code
path often tends to work with only one or two concrete types in practice.

This, to me, is one of the big insights of static typing—it takes that
insight and then says "Well, if we take as a given that variable types do
*tend* to be static, and we go a bit farther and *require* that, what can
we get in return?" It turns out to be a hell of a lot: better static
tooling, a better IDE experience, better performance, better memory usage,
fewer bugs, etc.

I believe as well that it is this way so the DartVM doesn't have to perform

Post by Filipe Morgado
complicated type inference and/or analysis and have fast startup times.

It's not just about type inference and startup time. Because the type
system is (wildly) unsound, even if we did all the inference in the world,
the VM still has to handle cases where the type analysis was wrong and
something fell through a hole in the type system.

Post by Filipe Morgado
But we end up with type checks all over the place and, sometimes maybe,
slow optimization/deoptimization cycles.
With a sound static type system, I think we could have 3 types of method
- Direct. We know a given instance is of a particular type, it wasn't
extended nor mixed in.
We call the method directly and may even inline it (provided we know
it's not null, NNBD ftw).
I believe most calls fall in this category.

1. A closed world assumption, i.e. whole program analysis. You need to
be able to see all of the classes in the entire program to tell if a given
method has been overridden or not. That tends to be slower and makes things
like dynamic loading harder.

2. Final or sealed classes. A way to say, "You know this method will not
be overridden because I am *declaring* that the class may not be
subclassed (or have its implicit interface implemented)."

3. Nonvirtual or final methods. Sort of the more fine-grained approach
to #2. A way to say, "I am declaring that this method may not be
overridden."

With one of those, you're able to statically tell if a given invocation
will always invoke a known method.

Post by Filipe Morgado
- vTable. We know the type implements a given interface. The type
provides a method table for that interface.
We call the method through one single indirection (provided we
efficiently get that table and the instance is not null, NNBD ftw).
I believe most polymorphic calls fall in this category.
Yup. This is basically Go's approach. Go gives you some of the feel of

dynamic typing by being structurally typed. But every "dynamic" invocation
is always through some known interface type.

Post by Filipe Morgado
- Dynamic. We don't know the exact type so the call site behaves as
currently implemented (and explained above).
With union types, I believe dynamism would be used very rarely, mostly
when dealing with external sources such as Json.
Yes. I like C#'s approach here, which is that "dynamic" is a special type

sort of on the side of the rest of the type system. A variable who's type
is "dynamic" kind of reinterprets the invocation syntax to mean something
else, more like a property lookup.

Post by Filipe Morgado
We should pay the price of dynamism and/or polymorphism only when we
actually need it.

With the VM, this is actually more or less true, at least when it comes to
method dispatch. The VM is really good at optimizing this stuff.

Where we get really hurt is:

1. Places where we need to statically compile Dart and care about the
resulting code size: dart2js.
2. Places where we cannot run a JIT: iOS.
3. Memory usage and the performance implications of it.

The last one, I think, may be the biggest performance hit for us. Not
having rigidly statically typed fields and local variables makes it harder
to allocate objects on the stack or in place inside an instance. You end up
with Java's model where you have a huge cloud of little objects with tons
of references between them. All of that indirection is really hard on cache
and memory usage.

I believe this is a strong argument for sound static types and fully

Post by Filipe Morgado
annotated/inferred/optimized Dart programs.

+1.

If you look at all of the languages that are widely used on client devices,
they are almost all statically typed: C/C++ (embedded, game consoles, lots
of mobile apps), Java (Android), Swift (iOS).

Objective-C is an interesting outlier because it has dynamic dispatch, but
a big part of it is the ability to opt *out* of that and drop down to bare
C semantics. Performance critical code like physics engines invariably do
that.

Cheers!

– bob

[Daniel Joyce]

Having dabbled in python again, yes to types and inference. As it is Dart
typing is too loose to be useful. Especially when throw async functions
into the mix, every function now returns "Future<_>" according to the
analyzer which is completely useless ( because dart generics are so weak ).
So then you have to go back and sprinkler in more types because inferencing
is so bad.

Analyzers "Missing/undeclared method/variable" warnings should be errors
90% of the time and cause compile failures because they are most often
typos.

Yeah sure, it sometimes works if you are calling a method on a Element that
you know exists because the element is really a CanvasElement, but this is
a rare. I've had more programs fail due to these 'warnings' than succeed
because I ignore them.

The automatic downcast nonsense has got to go too.

Its ridiculous that dart inherited this wishy-washy type system to be
'attractive' to javascript developers but then the javascript interop is
soo terrible.

For various reasons, I am porting my Chrome app to TypeScript, and I am
finding the combination of TypeScript's flexible type system and jslint is
catching more errors than the Dart type system. And the Interop is
relatively painless.

On Thu, Oct 1, 2015 at 9:17 AM 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Filipe Morgado
As I understand it, at every call site, a (slow) dynamic lookup is
performed on the receiver.
Once a type is encountered a sufficient number of times, the call site is
recompiled with an optimized path for that particular type.

Pretty much, yes.

Post by Filipe Morgado
If too many types are encountered, all optimizations are thrown away and
dynamic lookup is always used.

Also true, though it's worth noting that this happens fairly rarely in
practice. Even in completely dynamically typed languages, any given code
path often tends to work with only one or two concrete types in practice.
This, to me, is one of the big insights of static typing—it takes that
insight and then says "Well, if we take as a given that variable types do
*tend* to be static, and we go a bit farther and *require* that, what can
we get in return?" It turns out to be a hell of a lot: better static
tooling, a better IDE experience, better performance, better memory usage,
fewer bugs, etc.
I believe as well that it is this way so the DartVM doesn't have to

Post by Filipe Morgado
perform complicated type inference and/or analysis and have fast startup
times.

It's not just about type inference and startup time. Because the type
system is (wildly) unsound, even if we did all the inference in the world,
the VM still has to handle cases where the type analysis was wrong and
something fell through a hole in the type system.

Post by Filipe Morgado
But we end up with type checks all over the place and, sometimes maybe,
slow optimization/deoptimization cycles.
With a sound static type system, I think we could have 3 types of method
- Direct. We know a given instance is of a particular type, it wasn't
extended nor mixed in.
We call the method directly and may even inline it (provided we know
it's not null, NNBD ftw).
I believe most calls fall in this category.

1. A closed world assumption, i.e. whole program analysis. You need to
be able to see all of the classes in the entire program to tell if a given
method has been overridden or not. That tends to be slower and makes things
like dynamic loading harder.
2. Final or sealed classes. A way to say, "You know this method will
not be overridden because I am *declaring* that the class may not be
subclassed (or have its implicit interface implemented)."
3. Nonvirtual or final methods. Sort of the more fine-grained approach
to #2. A way to say, "I am declaring that this method may not be
overridden."
With one of those, you're able to statically tell if a given invocation
will always invoke a known method.

Post by Filipe Morgado
- vTable. We know the type implements a given interface. The type
provides a method table for that interface.
We call the method through one single indirection (provided we
efficiently get that table and the instance is not null, NNBD ftw).
I believe most polymorphic calls fall in this category.
Yup. This is basically Go's approach. Go gives you some of the feel of

dynamic typing by being structurally typed. But every "dynamic" invocation
is always through some known interface type.

Post by Filipe Morgado
- Dynamic. We don't know the exact type so the call site behaves as
currently implemented (and explained above).
With union types, I believe dynamism would be used very rarely,
mostly when dealing with external sources such as Json.
Yes. I like C#'s approach here, which is that "dynamic" is a special type

sort of on the side of the rest of the type system. A variable who's type
is "dynamic" kind of reinterprets the invocation syntax to mean something
else, more like a property lookup.

Post by Filipe Morgado
We should pay the price of dynamism and/or polymorphism only when we
actually need it.

With the VM, this is actually more or less true, at least when it comes to
method dispatch. The VM is really good at optimizing this stuff.
1. Places where we need to statically compile Dart and care about the
resulting code size: dart2js.
2. Places where we cannot run a JIT: iOS.
3. Memory usage and the performance implications of it.
The last one, I think, may be the biggest performance hit for us. Not
having rigidly statically typed fields and local variables makes it harder
to allocate objects on the stack or in place inside an instance. You end up
with Java's model where you have a huge cloud of little objects with tons
of references between them. All of that indirection is really hard on cache
and memory usage.
I believe this is a strong argument for sound static types and fully

Post by Filipe Morgado
annotated/inferred/optimized Dart programs.

+1.
If you look at all of the languages that are widely used on client
devices, they are almost all statically typed: C/C++ (embedded, game
consoles, lots of mobile apps), Java (Android), Swift (iOS).
Objective-C is an interesting outlier because it has dynamic dispatch, but
a big part of it is the ability to opt *out* of that and drop down to
bare C semantics. Performance critical code like physics engines invariably
do that.
Cheers!
– bob
--
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
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

['John Messerly' via Dart Misc]

On Thu, Oct 1, 2015 at 9:16 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Filipe Morgado
- Dynamic. We don't know the exact type so the call site behaves as
currently implemented (and explained above).
With union types, I believe dynamism would be used very rarely,
mostly when dealing with external sources such as Json.
Yes. I like C#'s approach here, which is that "dynamic" is a special type

sort of on the side of the rest of the type system. A variable who's type
is "dynamic" kind of reinterprets the invocation syntax to mean something
else, more like a property lookup.

Not sure I entirely follow this.

When using `dynamic` in C#, it should feel like C# is a dynamic language,
for those operations. That was our intention, at least. :-)

All of the normal C# rules (e.g. for method invocation, operators,
conversions) apply, but they use the actual types of the objects as they're
known at runtime, instead of the statically declared types at compile time.
And those types can change every time that call site is reached.

It's basically the same as leaving off type annotations in Dart.

['John Messerly' via Dart Misc]

Post by 'John Messerly' via Dart Misc
On Thu, Oct 1, 2015 at 9:16 AM, 'Bob Nystrom' via Dart Misc <

Post by Filipe Morgado
- Dynamic. We don't know the exact type so the call site behaves as
currently implemented (and explained above).
With union types, I believe dynamism would be used very rarely,
mostly when dealing with external sources such as Json.
Yes. I like C#'s approach here, which is that "dynamic" is a special

type sort of on the side of the rest of the type system. A variable who's
type is "dynamic" kind of reinterprets the invocation syntax to mean
something else, more like a property lookup.

Not sure I entirely follow this.
When using `dynamic` in C#, it should feel like C# is a dynamic language,
for those operations. That was our intention, at least. :-)
All of the normal C# rules (e.g. for method invocation, operators,
conversions) apply, but they use the actual types of the objects as they're
known at runtime, instead of the statically declared types at compile time.
And those types can change every time that call site is reached.
It's basically the same as leaving off type annotations in Dart.

Addendum: and if anyone's curious how it's implemented in C#, I can
probably answer, feel free to ask. :)

The basic idea is to keep part of the C# compiler around at runtime, and
when the dynamic call site is hit, trigger the compiler to figure out what
it would've done at compile time, and do that. Then add some of the typical
dynamic language optimization tricks (e.g. if you see the same operation
and types again, skip all of that work & just jump to already compiled code
for it).

['Bob Nystrom' via Dart Misc]

On Thu, Oct 1, 2015 at 9:32 AM, 'John Messerly' via Dart Misc <

Post by Filipe Morgado
Yes. I like C#'s approach here, which is that "dynamic" is a special type

Post by 'Bob Nystrom' via Dart Misc
sort of on the side of the rest of the type system. A variable who's type
is "dynamic" kind of reinterprets the invocation syntax to mean something
else, more like a property lookup.

Not sure I entirely follow this.
When using `dynamic` in C#, it should feel like C# is a dynamic language,
for those operations. That was our intention, at least. :-)
All of the normal C# rules (e.g. for method invocation, operators,
conversions) apply, but they use the actual types of the objects as they're
known at runtime, instead of the statically declared types at compile time.
And those types can change every time that call site is reached.
It's basically the same as leaving off type annotations in Dart.

I did a poor job of explaining this. :(

What I meant to convey was more just the idea that if you don't opt *in* to
the explicitly annotated "dynamic" type, you get normal
statically-typed+vtable dispatch. When you *do*, a variable that has that
type now reinterprets the "." to mean "do everything at runtime that would
have done at compile time given the type" like you say.

"dynamic" doesn't mean "didn't bother to annotate", it means, "wanted to
opt in to runtime type lookup and dispatch". It's a type annotation, but
it's also a "behavior specifier" for "." in the same way that "int" or
"double" specifies what "+" means on the operands.

Does that sound about right?

– bob

['John Messerly' via Dart Misc]

On Thu, Oct 1, 2015 at 9:49 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Thu, Oct 1, 2015 at 9:32 AM, 'John Messerly' via Dart Misc <

Post by Filipe Morgado
Yes. I like C#'s approach here, which is that "dynamic" is a special type

Post by 'Bob Nystrom' via Dart Misc
sort of on the side of the rest of the type system. A variable who's type
is "dynamic" kind of reinterprets the invocation syntax to mean something
else, more like a property lookup.

Not sure I entirely follow this.
When using `dynamic` in C#, it should feel like C# is a dynamic language,
for those operations. That was our intention, at least. :-)
All of the normal C# rules (e.g. for method invocation, operators,
conversions) apply, but they use the actual types of the objects as they're
known at runtime, instead of the statically declared types at compile time.
And those types can change every time that call site is reached.
It's basically the same as leaving off type annotations in Dart.

I did a poor job of explaining this. :(
What I meant to convey was more just the idea that if you don't opt *in* to
the explicitly annotated "dynamic" type, you get normal
statically-typed+vtable dispatch. When you *do*, a variable that has that
type now reinterprets the "." to mean "do everything at runtime that would
have done at compile time given the type" like you say.
"dynamic" doesn't mean "didn't bother to annotate", it means, "wanted to
opt in to runtime type lookup and dispatch". It's a type annotation, but
it's also a "behavior specifier" for "." in the same way that "int" or
"double" specifies what "+" means on the operands.
Does that sound about right?

Sort of. C# grammar requires type annotations for everything though, so you
have to pick what kind of dispatch you want, static or dynamic.

One thing that worked out pretty well (IMHO), is we made `dynamic` work
well with local type inference: if your expression is dynamic, the result
is dynamic. So you can do:

dynamic foo = ...;
var a = foo.bar();
var b = a.baz();
WriteLine(b);


...both `a` and `b` become dynamic.

Same thing with, e.g. generics. When you make a List<T> you can chose to
have it be some known type, like List<int>, or you can do List<dynamic>.

It wouldn't be too hard to retrofit C# such that you can leave off type
annotations, and it implies `dynamic`. It would basically just be a
grammar/parser feature. But I don't think there has been much demand for it
(especially since VB.net exists).

[Filipe Morgado]

Thanks for the answer, Bob.

Post by 'Bob Nystrom' via Dart Misc
This, to me, is one of the big insights of static typing—it takes that
insight and then says "Well, if we take as a given that variable types do
*tend* to be static, and we go a bit farther and *require* that, what can
we get in return?" It turns out to be a hell of a lot: better static
tooling, a better IDE experience, better performance, better memory usage,
fewer bugs, etc.

+1

Post by 'Bob Nystrom' via Dart Misc
With a sound static type system, I think we could have 3 types of method

Post by Filipe Morgado
- Direct. We know a given instance is of a particular type, it wasn't
extended nor mixed in.
We call the method directly and may even inline it (provided we know
it's not null, NNBD ftw).
I believe most calls fall in this category.

1. A closed world assumption, i.e. whole program analysis. You need to
be able to see all of the classes in the entire program to tell if a given
method has been overridden or not. That tends to be slower and makes things
like dynamic loading harder.
2. Final or sealed classes. A way to say, "You know this method will
not be overridden because I am *declaring* that the class may not be
subclassed (or have its implicit interface implemented)."
3. Nonvirtual or final methods. Sort of the more fine-grained approach
to #2. A way to say, "I am declaring that this method may not be
overridden."
With one of those, you're able to statically tell if a given invocation
will always invoke a known method.

One of the things that first attracted me to Dart was that it looked like a
better AS3.
But I still miss a few things from there.

- Dynamic loading
- Dynamic invocation (without reflection, point["x"] = 50 while still
being type-safe)
- ... a few other details ...
- And final classes/methods

I'm final by default everywhere. It's a little performance boost on
performance-critical code.

Libraries like StageXL, Box2D, etc (Sky/Flutter probably has a few
use-cases as well) use Point, Rectangle, Matrix, etc extensively.
Since those classes are (usually) not extended, they would benefit a lot
with polymorphism being optimized away (and some inlining).
(I don't know the extent of the optimizations done by the VM on that front).

Direct calls could be used at any given call site, even if the class is
extended elsewhere, if it can be statically determined that no other class
can reach that call site.

Post by 'Bob Nystrom' via Dart Misc
Not having rigidly statically typed fields and local variables makes it
harder to allocate objects on the stack or in place inside an instance. You
end up with Java's model where you have a huge cloud of little objects with
tons of references between them. All of that indirection is really hard on
cache and memory usage.

Conceptually, +1000 for on-stack or in-object instances, but ... could it
work?

Regarding embed instance, given the following code:
class Sprite {
final Point position = new Position(0, 0);
final Size size = new Size(100, 100);
}

bool isAtZero(Point point) => point.x == 0 && point.y == 0;

void main() {
final sprite = new Sprite();
print(isAtZero(sprite.position));
}

If both #position and #size are inlined/embed in sprite, would the function
isAtZero still be able to use dynamic dispatch on the point instance?
What about assignability to/from those members?

The only way I see it working is if instances do not reference their
classes, but we carry (pointer-to-class, pointer-to-instance) pairs
whenever we need polymorphism. So methods can work with both boxed and
embed instances. (But what do I know ...)

And regarding on-stack allocations, given the following code:
void main() {
final p1 = new Point(0, 0);
final p2 = new Point(100, 100);
print(p1.distanceTo(p2));
}

If both p1 and p2 are on-stack, we would need to make sure their reference
do not outlive their scope.
Wouldn't we need some kind of borrowing concept to make sure a function
does not store a given argument elsewhere?

On a side note ...

The web is getting Wasm (apparently, it will take a while to be useful to
high-level languages, if ever).
Mozilla is investing in Rust (which can easily run in Wasm).
Apple has Swift (probably on Wasm as well, in a near-future).
Micro$oft has .NET which will target any platform and probably transpile to
JS.

I'm not sure what's Google's plan is regarding Dart (or regarding anything
else, as a matter fact).
But I think it wouldn't hurt to get a few low-level features to be
competitive on mobile.

Well ... My 2 cts and doubts ...

[tatumizer-v0.2]

Did anyone consider the option to make type annotations mandatory, but add
a bit of sugar with constructs like:
List<String> list = new &(); // where '&' stands for declared type, in this
case List<String>

This removes the need in type inferences and eliminates irritating
redundancy in
List<String> list = new List<String>();

Java goes half way to this by allowing
ArrayList<String> list=new ArrayList<>();
but it's irritating still: we have to repeat "ArrayList" twice.

I know a couple of possible limitations, if you want to declare
ArrayList<String> list1=list;
then you need redundant declaration - compiler could derive type of list1
from assignment.
There are other situations like that.

My point (actually, a conjecture) is that those cases are either
statistically rare, or involve "short" types like int or String where you
don't gain much by writing "var" instead.

If the further "gains" are statistically small, then it doesn't make sense
for the language to target "long tail" at all. With ampersand (or something
equivalent) used as shortcut we already get 90% of all possible benefits.
All type declarations are explicit, no "type inference" required.

Opinions? Maybe I'm missing some important use case, so it's not 90%, but
much less?

[Daniel Joyce]

Why not the scala way? var x = List[String]()

it is then blindingly obvious the type of x.

Post by tatumizer-v0.2
Did anyone consider the option to make type annotations mandatory, but add
List<String> list = new &(); // where '&' stands for declared type, in
this case List<String>
This removes the need in type inferences and eliminates irritating
redundancy in
List<String> list = new List<String>();
Java goes half way to this by allowing
ArrayList<String> list=new ArrayList<>();
but it's irritating still: we have to repeat "ArrayList" twice.
I know a couple of possible limitations, if you want to declare
ArrayList<String> list1=list;
then you need redundant declaration - compiler could derive type of list1
from assignment.
There are other situations like that.
My point (actually, a conjecture) is that those cases are either
statistically rare, or involve "short" types like int or String where you
don't gain much by writing "var" instead.
If the further "gains" are statistically small, then it doesn't make sense
for the language to target "long tail" at all. With ampersand (or something
equivalent) used as shortcut we already get 90% of all possible benefits.
All type declarations are explicit, no "type inference" required.
Opinions? Maybe I'm missing some important use case, so it's not 90%, but
much less?
--
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
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[Daniel Joyce]

The type along with the value is assigned to the LHS.

Post by Daniel Joyce
Why not the scala way? var x = List[String]()
it is then blindingly obvious the type of x.

Post by tatumizer-v0.2
Did anyone consider the option to make type annotations mandatory, but
List<String> list = new &(); // where '&' stands for declared type, in
this case List<String>
This removes the need in type inferences and eliminates irritating
redundancy in
List<String> list = new List<String>();
Java goes half way to this by allowing
ArrayList<String> list=new ArrayList<>();
but it's irritating still: we have to repeat "ArrayList" twice.
I know a couple of possible limitations, if you want to declare
ArrayList<String> list1=list;
then you need redundant declaration - compiler could derive type of list1
from assignment.
There are other situations like that.
My point (actually, a conjecture) is that those cases are either
statistically rare, or involve "short" types like int or String where you
don't gain much by writing "var" instead.
If the further "gains" are statistically small, then it doesn't make
sense for the language to target "long tail" at all. With ampersand (or
something equivalent) used as shortcut we already get 90% of all possible
benefits. All type declarations are explicit, no "type inference" required.
Opinions? Maybe I'm missing some important use case, so it's not 90%, but
much less?
--
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
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce
The meek shall inherit the Earth, for the brave will be among the stars.

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[Filipe Morgado]

Post by Daniel Joyce
Why not the scala way? var x = List[String]()
it is then blindingly obvious the type of x.

+1

The analyzer should actually infer types instead of requiring annotations
almost everywhere to do its job.

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2
Opinions? Maybe I'm missing some important use case, so it's not 90%, but
much less?

I think most users expect type inference to be bottom-up and flow outward
from subexpressions. That's how it works in Scala, C++ (auto), C# (except
for lambda parameters), TypeScript, etc.

It also follows the general rule that the static type of an expression is
based on its subexpressions. In Dart, if you do:

foo.bar()


It already knows the type of that entire expression based on the type of foo
and the return type of it's bar() method. Instead of:

List<String> list = new &();


I'd much rather just do:

var list = [];


This is valid syntax in JS, TypeScript, Scala (I think?), etc. It would be
great if this existing familiar syntax also have type inference that just
worked.

Cheers!

– bob

['John Messerly' via Dart Misc]

On Thu, Oct 1, 2015 at 2:28 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by tatumizer-v0.2
Opinions? Maybe I'm missing some important use case, so it's not 90%, but
much less?

I think most users expect type inference to be bottom-up and flow outward
from subexpressions. That's how it works in Scala, C++ (auto), C# (except
for lambda parameters), TypeScript, etc.
It also follows the general rule that the static type of an expression is
foo.bar()
It already knows the type of that entire expression based on the type of
List<String> list = new &();
var list = [];
This is valid syntax in JS, TypeScript, Scala (I think?), etc. It would be
great if this existing familiar syntax also have type inference that just
worked.

There's nothing to help infer the generic parameter type there. Did you
mean:

var list = <String>[];

Post by 'Bob Nystrom' via Dart Misc
Cheers!
– bob
--
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
To unsubscribe from this group and stop receiving emails from it, send an

[Daniel Joyce]

Yes, types should definitely float to the LHS.

On Thu, Oct 1, 2015 at 2:32 PM 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
On Thu, Oct 1, 2015 at 2:28 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by tatumizer-v0.2
Opinions? Maybe I'm missing some important use case, so it's not 90%,
but much less?

I think most users expect type inference to be bottom-up and flow outward
from subexpressions. That's how it works in Scala, C++ (auto), C# (except
for lambda parameters), TypeScript, etc.
It also follows the general rule that the static type of an expression is
foo.bar()
It already knows the type of that entire expression based on the type of
List<String> list = new &();
var list = [];
This is valid syntax in JS, TypeScript, Scala (I think?), etc. It would
be great if this existing familiar syntax also have type inference that
just worked.

There's nothing to help infer the generic parameter type there. Did you
var list = <String>[];

Post by 'Bob Nystrom' via Dart Misc
Cheers!
– bob
--
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
To unsubscribe from this group and stop receiving emails from it, send an

--
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
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

['Bob Nystrom' via Dart Misc]

On Thu, Oct 1, 2015 at 2:31 PM, 'John Messerly' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
This is valid syntax in JS, TypeScript, Scala (I think?), etc. It would be

Post by 'Bob Nystrom' via Dart Misc
great if this existing familiar syntax also have type inference that just
worked.

There's nothing to help infer the generic parameter type there. Did you
var list = <String>[];

Oops, yes!

– bob

[tatumizer-v0.2]

Here's a (probably, incomplete) list of arguments against scala-style
inference in dart:
1) in dart, this won't be backward compatible.

2) as soon as we start "inferring", it's not clear where to end. What is
the inferred type in
var x;
// ...
x="Hello";
Is it a String? When you read the code, it's not obvious - you have to scan
many lines to see the assignment.
Another example:
var x = foo==bar? "blah" : "blahblah";
is it a String? Then how about this:
var x= someCond? "blah": 0;
What is the type of x? BTW, this is, most likely, a bug, which doesn't get
reported.
According to what I just ungoogled, in scala, the inference is limited to
specific contexts, but it's difficult to justify why it works in some
contexts, and not in others.

3) It makes explicit declarations "uncool". Sure, when you write a program,
it's easier to write
var x=foo();
but when you read it, you wonder what foo() return type is. So, while
writing, you may complain about the lack of inference, but while reading,
you may complain about the opposite.

4) with explicit declarations, type is on the left, but with inference,
it's on the right, and just "flows" to the left (or, with more advanced
inference, flows from 10 feet below). This may cause headache or worse.
(Manipulations with mouse in IDE just to see what type is inferred is
ridiculous IMO).

5) This is subjective, but based on my own java experience, I get mad
mostly when I have to write type BOTH on the left AND on the right, like in
ArrayList<String> list=new ArrayList<>();
This thing is just bad!!! In other contexts, it's not that dramatic.

Again, it's my conjecture (unproven) that in most of the cases where you
call foo(), whatever it is, it returns something simple like int or String,
and writing "var x=foo()" is not much easier than "String x=foo()". And if
it returns something more complicated, then explicit type declaration helps
more than it hurts.

[Gen]

I do not see why "var x" would not work. If not then maybe it is time for a
language break.
I see no problem with type inference using statements from below. Variables
are typed in checked mode.
I also like the alignment of the variable names when using "var" or "let".
Besides some people have nothing against optional type annotations on the
right side like in most other recent languages.
I find Java rather annoying because type annotations are required.
With regard to your example, most often a type annotation involves an
interface name and the constructor call involves a class name.

Post by tatumizer-v0.2
Here's a (probably, incomplete) list of arguments against scala-style
1) in dart, this won't be backward compatible.
2) as soon as we start "inferring", it's not clear where to end. What is
the inferred type in
var x;
// ...
x="Hello";
Is it a String? When you read the code, it's not obvious - you have to
scan many lines to see the assignment.
var x = foo==bar? "blah" : "blahblah";
var x= someCond? "blah": 0;
What is the type of x? BTW, this is, most likely, a bug, which doesn't get
reported.
According to what I just ungoogled, in scala, the inference is limited to
specific contexts, but it's difficult to justify why it works in some
contexts, and not in others.

3) It makes explicit declarations "uncool". Sure, when you write a program,

Post by tatumizer-v0.2
it's easier to write
var x=foo();
but when you read it, you wonder what foo() return type is. So, while
writing, you may complain about the lack of inference, but while reading,
you may complain about the opposite.
4) with explicit declarations, type is on the left, but with inference,
it's on the right, and just "flows" to the left (or, with more advanced
inference, flows from 10 feet below). This may cause headache or worse.
(Manipulations with mouse in IDE just to see what type is inferred is
ridiculous IMO).
5) This is subjective, but based on my own java experience, I get mad
mostly when I have to write type BOTH on the left AND on the right, like in
ArrayList<String> list=new ArrayList<>();
This thing is just bad!!! In other contexts, it's not that dramatic.
Again, it's my conjecture (unproven) that in most of the cases where you
call foo(), whatever it is, it returns something simple like int or String,
and writing "var x=foo()" is not much easier than "String x=foo()". And if
it returns something more complicated, then explicit type declaration helps
more than it hurts.

[Jan Mostert]

Quote:
"Java goes half way to this by allowing
ArrayList<String> list=new ArrayList<>(); "

Actually in Java, List is an interface and you should rather do:
List<String> list = new ArrayList<>();
or
List<String> list = new LinkedList<>();

With IDE autocompleting this the whole time using templates, I'm hardly
typing any code and reading it you can see exactly what you're looking at.

Post by Gen
I do not see why "var x" would not work. If not then maybe it is time for
a language break.
I see no problem with type inference using statements from below.
Variables are typed in checked mode.
I also like the alignment of the variable names when using "var" or "let".
Besides some people have nothing against optional type annotations on the
right side like in most other recent languages.
I find Java rather annoying because type annotations are required.
With regard to your example, most often a type annotation involves an
interface name and the constructor call involves a class name.

Post by tatumizer-v0.2
Here's a (probably, incomplete) list of arguments against scala-style
1) in dart, this won't be backward compatible.
2) as soon as we start "inferring", it's not clear where to end. What is
the inferred type in
var x;
// ...
x="Hello";
Is it a String? When you read the code, it's not obvious - you have to
scan many lines to see the assignment.
var x = foo==bar? "blah" : "blahblah";
var x= someCond? "blah": 0;
What is the type of x? BTW, this is, most likely, a bug, which doesn't
get reported.
According to what I just ungoogled, in scala, the inference is limited to
specific contexts, but it's difficult to justify why it works in some
contexts, and not in others.

3) It makes explicit declarations "uncool". Sure, when you write a

Post by tatumizer-v0.2
program, it's easier to write
var x=foo();
but when you read it, you wonder what foo() return type is. So, while
writing, you may complain about the lack of inference, but while reading,
you may complain about the opposite.
4) with explicit declarations, type is on the left, but with inference,
it's on the right, and just "flows" to the left (or, with more advanced
inference, flows from 10 feet below). This may cause headache or worse.
(Manipulations with mouse in IDE just to see what type is inferred is
ridiculous IMO).
5) This is subjective, but based on my own java experience, I get mad
mostly when I have to write type BOTH on the left AND on the right, like in
ArrayList<String> list=new ArrayList<>();
This thing is just bad!!! In other contexts, it's not that dramatic.
Again, it's my conjecture (unproven) that in most of the cases where you
call foo(), whatever it is, it returns something simple like int or String,
and writing "var x=foo()" is not much easier than "String x=foo()". And if
it returns something more complicated, then explicit type declaration helps
more than it hurts.
--

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
To unsubscribe from this group and stop receiving emails from it, send an

[tatumizer-v0.2]

@Jan: I don't completely follow your argument. We are discussing it in the
context of type inference. Suppose java would add type inference, and allow
var list=new ArrayList<String>();
Would you complain: no, I don't want "list" to have type ArrayList<String>,
I want List<String>, so you go ahead and rewrite the above as
List<String>=new ArrayList<>();

What is the point of hiding real type of list in a local context anyway?
The reason you can sometimes see it in java might be: it makes it a bit
shorter (or maybe it looks more "sophisticated" in some quarters?).

Back to the topic: I had a modest suggestion: instead of
var list = new ArrayList<String>();
allow
ArrayList<String> list = new &();

My main argument is that it gives you same result and the same level of
convenience without going into rat hole of discussion of type inference and
its limits.
Thus. we can eliminate noise and frustration in 90% or so cases, and if you
target 100%, you never reach it - people become frustrated for opposite
reason (hard to figure out the type looking at the code)

Having uniform convention of declarations is important. If the type is on
the left, it should be on the left, and not sometimes here, but sometimes
there. But that's what you get with type inference:
var list=new List<String>(); // type on the right
List<String> myList=getMyList(); // type of the left

Compare with:
List<String> list = new &();
List<String> list1 = getMyList();

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2
Thus. we can eliminate noise and frustration in 90% or so cases, and if
you target 100%

Have you grepped a corpus to show that 90% of variable initializers
actually are constructor calls? My hunch is that the fraction is lower. If
I wasn't swamped with other stuff right now, I'd check it out for myself. :(

– bob

[Alex Tatumizer]

Even if you had time, it would be difficult to measure "frustration"
programmatically :( , :)

[Jan Mostert]

Post by tatumizer-v0.2
@Jan: I don't completely follow your argument. We are discussing it in the
context of type inference. Suppose java would add type inference, and allow
var list=new ArrayList<String>();
Would you complain: no, I don't want "list" to have type
ArrayList<String>, I want List<String>, so you go ahead and rewrite the
above as
List<String>=new ArrayList<>();

I get mad mostly when I have to write type BOTH on the left AND on the

Post by tatumizer-v0.2
right, like in ArrayList<String> list=new ArrayList<>();

Was just pointing out how lists (and many other things) are generally used
in Java (interface on the left, implementation<type> on the right), you
don't have to specify the type on the left and right. When you do specify
it on the left, you can leave it out on the right due to the <> operator.

I generally avoid type inference in Dart, strongly typed all the way,
unless I don't plan on using a certain returned variable, then I don't
bother adding a type.

The clear trend of modern statically typed languages is towards inferred

Post by tatumizer-v0.2
local variables: C#, Scala, Go, Swift, C++11, Kotlin, Rust, etc. At this
point, I believe reliable local variable inference is a basic requirement
for a language to succeed.

... and for type inference to be a usable feature in Dart, until then,
strongly typed all the way!


--
Jan Vladimir Mostert
janvladimirmostert.com

Post by tatumizer-v0.2
Even if you had time, it would be difficult to measure "frustration"
programmatically :( , :)
--
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
To unsubscribe from this group and stop receiving emails from it, send an

[Alex Tatumizer]

Post by Jan Mostert
I generally avoid type inference in Dart, strongly typed all the way,

unless I don't plan on using a certain returned variable, then I don't
bother adding a type.
You are not alone. Following Bob's comments, I went into dart repo to see
whether people really use unspecified "var" as often. E.g., l looked at
collection and convert libraries. Types are declared meticulously, for
every variable, with generics where applicable, except a few lines where
it's really obvious that the type is int. Which means at least some people
in the team feel more comfortable with explicit types, as I do.
Just one example (taken from
https://github.com/dart-lang/sdk/blob/master/sdk/lib/convert/convert.dart)

Stream<List<int>> stream = new File('quotes.txt').openRead();

If you erase annotation, then even with ideal type inference, it doesn't
help human reader of the program to make sense of it. Now what, you start
differentiating: here, I will put explicit annotation, and there, I put
just var? IMO, it's easier to keep everything uniform when you code. Still,
ampersand would help! :)

[Don Olmstead]

Honestly I think that more has to do with when stuff was created, convert
is pretty old in terms of commits, and how the analysis server handles the
inference at that time. I know I occasionally use casts when the analyzer
pukes on something, most likely having to do with async code, and then
later on when I'm working on the same bit of code it'll say that its
unnecessary so I take the cast out.

Post by Jan Mostert

Post by Jan Mostert
I generally avoid type inference in Dart, strongly typed all the way,

unless I don't plan on using a certain returned variable, then I don't
bother adding a type.
You are not alone. Following Bob's comments, I went into dart repo to see
whether people really use unspecified "var" as often. E.g., l looked at
collection and convert libraries. Types are declared meticulously, for
every variable, with generics where applicable, except a few lines where
it's really obvious that the type is int. Which means at least some people
in the team feel more comfortable with explicit types, as I do.
Just one example (taken from
https://github.com/dart-lang/sdk/blob/master/sdk/lib/convert/convert.dart)
Stream<List<int>> stream = new File('quotes.txt').openRead();
If you erase annotation, then even with ideal type inference, it doesn't
help human reader of the program to make sense of it. Now what, you start
differentiating: here, I will put explicit annotation, and there, I put
just var? IMO, it's easier to keep everything uniform when you code. Still,
ampersand would help! :)
--
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
To unsubscribe from this group and stop receiving emails from it, send an

[Alex Tatumizer]

OK, maybe it's old, but this one is recent:
https://github.com/flutter/engine/blob/master/examples/game/lib/player_state.dart
Not a single var there. Checked other examples - same thing.

[Alex Tatumizer]

@Bob: fine, let's agree that there are 2 different kinds of people:
somebody always puts annotations, somebody is fine with inference. The
thing is that the group that always uses annotations gets no help from the
language at all, so they need to write (taken from flutter examples):
ActionGroup group = new ActionGroup([spline, rotate, scale]);
whereas with ampersand, this would be
ActionGroup group = new &([spline, rotate, scale]);

Suppose "new" is made optional, then it's
ActionGroup group = ActionGroup([spline, rotate, scale]); // vs
ActionGroup group = &([spline, rotate, scale]);

I see quite a bit of difference between the two. I would certainly start
using ampersand where possible.

[Günter Zöchbauer]

I would use just final (or var) for local variables, but when
autocompletion doesn't work I add more type annotations. Type inference
never worked very well in the past and there are still several issues. Only
very recently type inference for `var x = await...` was fixed.

I guess trust in type inference will only evolve if the analyzer clearly
shows hints where the type can't be inferred. This is what I expect from
strong mode.

IMHO inferring a preference from existing code is just misleading.

Post by Alex Tatumizer
somebody always puts annotations, somebody is fine with inference. The
thing is that the group that always uses annotations gets no help from the
ActionGroup group = new ActionGroup([spline, rotate, scale]);
whereas with ampersand, this would be
ActionGroup group = new &([spline, rotate, scale]);
Suppose "new" is made optional, then it's
ActionGroup group = ActionGroup([spline, rotate, scale]); // vs
ActionGroup group = &([spline, rotate, scale]);
I see quite a bit of difference between the two. I would certainly start
using ampersand where possible.

['Bob Nystrom' via Dart Misc]

Post by Alex Tatumizer
You are not alone. Following Bob's comments, I went into dart repo to see
whether people really use unspecified "var" as often. E.g., l looked at
collection and convert libraries. Types are declared meticulously, for
every variable, with generics where applicable, except a few lines where
it's really obvious that the type is int. Which means at least some people
in the team feel more comfortable with explicit types, as I do.
Just one example (taken from
https://github.com/dart-lang/sdk/blob/master/sdk/lib/convert/convert.dart)
Stream<List<int>> stream = new File('quotes.txt').openRead();
If you erase annotation, then even with ideal type inference, it doesn't
help human reader of the program to make sense of it. Now what, you start
differentiating: here, I will put explicit annotation, and there, I put
just var? IMO, it's easier to keep everything uniform when you code. Still,
ampersand would help! :)

Different subteams on the Dart team have surprisingly different coding
styles. If you look at, say, pub <https://github.com/dart-lang/pub> or DDC
<https://github.com/dart-lang/dev_compiler>, you'll get a very different
picture.

Cheers!

– bob

[Daniel Joyce]

in scala, sometimes to make things clearer I add types when I don't have
to, especially with public apis. But I can always fall back on tooling. I
have no such guarantees in Dart.


foo() async {
return new Future(()=> 3);
}

All dart analyzer says is foo() -> dynamic, which is entirely worthless.

3) I can hover over foo() in my editor and gets its type in Scala. In dart,
the above code yields the worthless type info of foo() -> dynamic

4) if someone hasn't typed their code at all in Dart ( its optional
remember!) you are SOL in the dart editor. Hovering won't help you much. At
least in scala you can fall back and have the ide tell you. Or use the ide
autocomplete to write properly typed code because robust typing leads to
robust autocomplete.

At least in Scala, if I have the source, mouse hover would tell me the real
return type. With poor dart code, I get nothing.

So again, if we are dealing with 'bad terse Scala' lacking some types
sprinkled in to make it easier to read, I can fall back on tooling to
understand it. With 'bad terse Dart' I have no help.

With dart, unless you put types everywhere, tooling is no help. And if you
do put types everywhere to help with tooling, whats the point of "optional
typing"? Might as well use javascript or Python at that point.

Optional typing NEEDS robust inference if tooling is to succeed.

Post by tatumizer-v0.2
3) It makes explicit declarations "uncool". Sure, when you write a
program, it's easier to write
var x=foo();
but when you read it, you wonder what foo() return type is. So, while
writing, you may complain about the lack of inference, but while reading,
you may complain about the opposite.
4) with explicit declarations, type is on the left, but with inference,
it's on the right, and just "flows" to the left (or, with more advanced
inference, flows from 10 feet below). This may cause headache or worse.
(Manipulations with mouse in IDE just to see what type is inferred is
ridiculous IMO).
--

Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2
Here's a (probably, incomplete) list of arguments against scala-style
1) in dart, this won't be backward compatible.

This depends on what the inference is used for. If it's just for static
analysis and warnings, I don't think we consider it a breaking change if
new warnings appear. DDC's "strong mode" is doing this now.

Post by tatumizer-v0.2
2) as soon as we start "inferring", it's not clear where to end. What is
the inferred type in
var x;
// ...
x="Hello";
Is it a String? When you read the code, it's not obvious - you have to
scan many lines to see the assignment.

Inference for uninitialized variables is hard. I think the interesting
question is *why* doesn't the variable have an initializer? In many cases,
I think it's because the code looks like:

var x;
if (someLongCondition) {
// Do some work...
x = ...
} else {
// Do other work...
x = ...
}


One option would be to make if () and blocks usable in an expression
context. Then you could do:

var x = if (someLongCondition) {
// Do some work...
...
} else {
// Do other work...
...
}


I realize that would be a significant change to the language. Other options
would be to try to do more complex inference, or just require a type
annotation on uninitialized variables.

Post by tatumizer-v0.2
var x = foo==bar? "blah" : "blahblah";
var x= someCond? "blah": 0;
What is the type of x? BTW, this is, most likely, a bug, which doesn't get
reported.

The language already specifies this. It's the least upper bound of the two
arms. Otherwise, it would know how to handle type checking things like:

functionThatTakesInt(condition ? 123 : "not int");


According to what I just ungoogled, in scala, the inference is limited to

Post by tatumizer-v0.2
specific contexts, but it's difficult to justify why it works in some
contexts, and not in others.
3) It makes explicit declarations "uncool". Sure, when you write a
program, it's easier to write
var x=foo();
but when you read it, you wonder what foo() return type is. So, while
writing, you may complain about the lack of inference, but while reading,
you may complain about the opposite.

I think that code is totally cool, and I wouldn't complain about the lack
of annotations here. The name of the function should make it clear (not
necessarily it's static type, but the actual meaning of the object) what it
returns.

This is what *all* of my Dart code looks like, as does much of the Dart
that my coworkers write, and I don't have any problems reading it.

Post by tatumizer-v0.2
4) with explicit declarations, type is on the left, but with inference,
it's on the right, and just "flows" to the left (or, with more advanced
inference, flows from 10 feet below). This may cause headache or worse.
(Manipulations with mouse in IDE just to see what type is inferred is
ridiculous IMO).

<shrug>

Post by tatumizer-v0.2
5) This is subjective, but based on my own java experience, I get mad
mostly when I have to write type BOTH on the left AND on the right, like in
ArrayList<String> list=new ArrayList<>();
This thing is just bad!!! In other contexts, it's not that dramatic.
Again, it's my conjecture (unproven) that in most of the cases where you
call foo(), whatever it is, it returns something simple like int or String,
and writing "var x=foo()" is not much easier than "String x=foo()". And if
it returns something more complicated, then explicit type declaration helps
more than it hurts.

The clear trend of modern statically typed languages is towards inferred
local variables: C#, Scala, Go, Swift, C++11, Kotlin, Rust, etc. At this
point, I believe reliable local variable inference is a basic requirement
for a language to succeed.

Cheers,

– bob

[Kasper Peulen]

On Fri, Oct 2, 2015 at 6:15 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
Inference for uninitialized variables is hard. I think the interesting
question is *why* doesn't the variable have an initializer? In many
var x;
if (someLongCondition) {
// Do some work...
x = ...
} else {
// Do other work...
x = ...
}
One option would be to make if () and blocks usable in an expression
var x = if (someLongCondition) {
// Do some work...
...
} else {
// Do other work...
...
}
I realize that would be a significant change to the language. Other
options would be to try to do more complex inference, or just require a
type annotation on uninitialized variables.

What about this ?

var x = () {
if (someLongCondition) {
// Do some work...
...
} else {
// Do other work...
...
}();

I think no changes to language are needed for this. Maybe we could have
some sugar so that you could write it with more appealing syntax.

[tatumizer-v0.2]

This case is simple, you can just define more functions
someWork() { ...; return 0; }
otherWork() { ... return 1; }
var x= someCondition? someWork(): otherWork();

But there are many other cases where you can't do that.
E.g., you have 2 variables x and y:
var x, y ;
if (someCondition) {
// do some work
x = ...
y = ...
} else {
// do other work
x = ...;
y = ...
}

Sometimes, you need variables that get assigned in try/catch block, and you
want to use them outside the block.

Instance members are routinely left uninitialized, because they become
known only later (default "null" value means "yet unknown")

But even everything could be initialized, how can you guess that function
foo() in "var f=foo()" returns Stream<List<int>>? Compiler certainly can
figure it out, but human reader?

Regardless of this example, some programmers simply feel more comfortable
when they declare types explicitly. What can you do about it? Explain to
them it's irrational? They will argue that for them, it's rational because
it helps them read and understand their own program Sure, explicit typing
might be redundant, but there's useful redundancy and useless redundancy.
Huge level of useful redundancy can be found in natural language (link
<https://www.uni-due.de/~bj0063/doc/shannon_redundancy.pdf>) - otherwise we
would have problem even making sense of what the other guy says.


AK

['Bob Nystrom' via Dart Misc]

Post by Filipe Morgado

Post by 'Bob Nystrom' via Dart Misc
Not having rigidly statically typed fields and local variables makes it
harder to allocate objects on the stack or in place inside an instance. You
end up with Java's model where you have a huge cloud of little objects with
tons of references between them. All of that indirection is really hard on
cache and memory usage.

Conceptually, +1000 for on-stack or in-object instances, but ... could it
work?
class Sprite {
final Point position = new Position(0, 0);
final Size size = new Size(100, 100);
}
bool isAtZero(Point point) => point.x == 0 && point.y == 0;
void main() {
final sprite = new Sprite();
print(isAtZero(sprite.position));
}
If both #position and #size are inlined/embed in sprite, would the
function isAtZero still be able to use dynamic dispatch on the point
instance?
What about assignability to/from those members?

There are a few approaches we could take here. We could allow references
into the middle of an object, but that complicates the GC. I think Go does
this.

Or we could take C#'s approach and have a distinct notion of non-reference
types. In C#, if you declare Point using "struct" instead of "class", it
gets value semantics. That means in-place allocation on the stack and in
objects. It also means pass by value. So the code above would copy the
point when you call isAtZero(). That would work for this function because
it doesn't mutate it. If you did want to mutate the original point, you'd
need an explicit way to box it to refer to it by reference. (That's why C#
has "out" and "ref" params.)

Post by Filipe Morgado
The only way I see it working is if instances do not reference their
classes, but we carry (pointer-to-class, pointer-to-instance) pairs
whenever we need polymorphism. So methods can work with both boxed and
embed instances. (But what do I know ...)
void main() {
final p1 = new Point(0, 0);
final p2 = new Point(100, 100);
print(p1.distanceTo(p2));
}
If both p1 and p2 are on-stack, we would need to make sure their reference
do not outlive their scope.
Wouldn't we need some kind of borrowing concept to make sure a function
does not store a given argument elsewhere?

If you don't do pass by value and copy them, then, yes, you do. That's what
Go does. If it sees that a pointer to a local variable can escape the
function, then the local is actually allocated on the heap and boxed.

Post by Filipe Morgado
I'm not sure what's Google's plan is regarding Dart (or regarding anything
else, as a matter fact).
But I think it wouldn't hurt to get a few low-level features to be
competitive on mobile.

Totally agree.

Cheers!

– bob

[Filipe Morgado]

Post by 'Bob Nystrom' via Dart Misc
There are a few approaches we could take here. We could allow references
into the middle of an object, but that complicates the GC. I think Go does
this.
Or we could take C#'s approach and have a distinct notion of non-reference
types. In C#, if you declare Point using "struct" instead of "class", it
gets value semantics. That means in-place allocation on the stack and in
objects. It also means pass by value. So the code above would copy the
point when you call isAtZero(). That would work for this function because
it doesn't mutate it. If you did want to mutate the original point, you'd
need an explicit way to box it to refer to it by reference. (That's why C#
has "out" and "ref" params.)

I'm all for structs, but sooner or later we'll need to define methods for
those and probably a way to allocate them on the heap.
Wouldn't we end up having two incompatible ways to define objects that are
conceptually equivalent?
Structs are embed in other objects or on the stack and cannot be extended.
Classes may be extended/mixed-in but can only be allocated on the heap.

We would probably have libraries that use struct points/rectangle/etc, and
libraries that use classes.
Good luck interoperating those.

Wouldn't it be better to find a way to retrofit classes so they work as
structs as well?

Considering this example:
void main() {
final p1 = new Point(0, 0);
final p2 = new Point(100, 100);
print(p1.distanceTo(p2));
}

p1 and p2 are both final and their instance types are statically known.
Considering we don't do anything that requires them to be on the heap,
we have all the information we need to safely allocate them on the stack as
plain structures.
We may have to compile methods differently for structs and classes, but the
benefit is pretty big, I think.

And considering this example:
class Sprite {
struct position = new Point(0, 0);
struct size = new Size(100, 100);
}

bool isAtZero(Point point) => point.x == 0 && point.y == 0;

void main() {
final sprite = new Sprite();
print(isAtZero(sprite.position));
}

I introduce the "struct" keyword as an alternative to "final" "var" or
"const", which requires a statically known instance and initialization.
"struct" is equivalent to "final" but indicates that the instance is to be
embed in the parent structure, and may have semantic differences.
(This is not a proposal, just an illustration, as I'm not aware of
everything it entails).

This way, we wouldn't have to define both a struct and a class Point and
their respective functions.

I know it's problematic when it comes to dynamic dispatch and passing a
struct pointer to a method that expects a regular polymorphic reference.
But I wouldn't mind having this kind of structs even if in a very
restricted scenario.

I would love to be able to do something like this:
class Sprite extends Object with EventDispatcher {

struct position = new Point<num>(0, 0) {
@override
void set x (num value) {
super.x = value;
// dispatchEvent is on Sprite, not Point
dispatchEvent(new Event("POSITION_CHANGED"));
}

@override
void set y (num value) {
super.y = value;
// dispatchEvent is on Sprite, not Point
dispatchEvent(new Event("POSITION_CHANGED"));
}
};

Sprite();
}

And have the compiler/runtime automatically create anonymous/inner
classes/structs for #position.
Although I would write "mySprite.position.x = 50;", I would know that
mySprite and mySprite.position are actually the same object and only
requires one offset to access #x.

[Gen]

I do not know if struct values are that useful.
In C++, structs and classes are the same.
In Swift there are differences but I do not understand why
(https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ClassesAndStructures.html)
For .net, the use of struct values is hardly advised
(https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx)
And I would be surprised if the Dart VM team (especially Lars and Gilad)
liked struct values. They complicate the language and require (I guess)
static type information because they are not like objects.
Besides http://gbracha.blogspot.be/2009/05/original-sin.html
On the other hand, value types might be available in Java 10.

If I understand your idea correctly then you talk about inlined fields.
Can the VM not decide well enough when to inline what ?

Post by Filipe Morgado

Post by 'Bob Nystrom' via Dart Misc
There are a few approaches we could take here. We could allow references
into the middle of an object, but that complicates the GC. I think Go does
this.
Or we could take C#'s approach and have a distinct notion of
non-reference types. In C#, if you declare Point using "struct" instead of
"class", it gets value semantics. That means in-place allocation on the
stack and in objects. It also means pass by value. So the code above would
copy the point when you call isAtZero(). That would work for this function
because it doesn't mutate it. If you did want to mutate the original point,
you'd need an explicit way to box it to refer to it by reference. (That's
why C# has "out" and "ref" params.)

I'm all for structs, but sooner or later we'll need to define methods for
those and probably a way to allocate them on the heap.
Wouldn't we end up having two incompatible ways to define objects that are
conceptually equivalent?
Structs are embed in other objects or on the stack and cannot be extended.
Classes may be extended/mixed-in but can only be allocated on the heap.
We would probably have libraries that use struct points/rectangle/etc, and
libraries that use classes.
Good luck interoperating those.
Wouldn't it be better to find a way to retrofit classes so they work as
structs as well?
void main() {
final p1 = new Point(0, 0);
final p2 = new Point(100, 100);
print(p1.distanceTo(p2));
}
p1 and p2 are both final and their instance types are statically known.
Considering we don't do anything that requires them to be on the heap,
we have all the information we need to safely allocate them on the stack
as plain structures.
We may have to compile methods differently for structs and classes, but
the benefit is pretty big, I think.
class Sprite {
struct position = new Point(0, 0);
struct size = new Size(100, 100);
}
bool isAtZero(Point point) => point.x == 0 && point.y == 0;
void main() {
final sprite = new Sprite();
print(isAtZero(sprite.position));
}
I introduce the "struct" keyword as an alternative to "final" "var" or
"const", which requires a statically known instance and initialization.
"struct" is equivalent to "final" but indicates that the instance is to be
embed in the parent structure, and may have semantic differences.
(This is not a proposal, just an illustration, as I'm not aware of
everything it entails).
This way, we wouldn't have to define both a struct and a class Point and
their respective functions.
I know it's problematic when it comes to dynamic dispatch and passing a
struct pointer to a method that expects a regular polymorphic reference.
But I wouldn't mind having this kind of structs even if in a very
restricted scenario.
class Sprite extends Object with EventDispatcher {
struct position = new Point<num>(0, 0) {
@override
void set x (num value) {
super.x = value;
// dispatchEvent is on Sprite, not Point
dispatchEvent(new Event("POSITION_CHANGED"));
}
@override
void set y (num value) {
super.y = value;
// dispatchEvent is on Sprite, not Point
dispatchEvent(new Event("POSITION_CHANGED"));
}
};
Sprite();
}
And have the compiler/runtime automatically create anonymous/inner
classes/structs for #position.
Although I would write "mySprite.position.x = 50;", I would know that
mySprite and mySprite.position are actually the same object and only
requires one offset to access #x.

[Filipe Morgado]

Post by Gen
I do not know if struct values are that useful.
For .net, the use of struct values is hardly advised (
https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx)
And I would be surprised if the Dart VM team (especially Lars and Gilad)
liked struct values. They complicate the language and require (I guess)
static type information because they are not like objects.
Besides http://gbracha.blogspot.be/2009/05/original-sin.html
On the other hand, value types might be available in Java 10.
If I understand your idea correctly then you talk about inlined fields.
Can the VM not decide well enough when to inline what ?

Language-wise, I agree. There's nothing we could do with structs that we
can't with regular classes (if we disregard GC pressure).

But performance-wise (#perfmatters was everywhere when Dart was launched),
it's a game-changer.
Since we want to go mobile and IoT, it's quite relevant.
Besides, it would really favor composition, without performance degradation.

I don't think the VM performs this kind of optimizations.
It maybe could stack-allocate a few things.
But I don't think there's enough information/guaranties to inline class
fields inside other classes.
And it's probably impossible if mirrors are used.

[Gen]

The combination of variables that can not reference null and sealed classes
might help with regard to performance.
But even then value types and a compiler that optimizes based on types
might make sense.
Maybe it is time to rethink the Dart platform because IMHO:
- Dart does not replace Javascript and it was never the goal according to
official sources.
- The top 5 or top 10 programming languages (will) compile to Ecmascript or
web assembly.
- Dart and its optional types do not appeal particularly to either dynamic
nor static type proponents.
What is the programming culture with Dart ? Explicit types, complex API for
engineers, classic compilation, classic tools.
- Dart (and its libraries) is not simple. Professional programming is not
simple. No successful general purpose language is simple. Even Ecmascript
is very large and complex.
I have nothing against more ways that make Dart a valid choice for whatever
purpose. This includes threads and value types if there is no better
alternative.

Post by Filipe Morgado

Post by Gen
I do not know if struct values are that useful.
For .net, the use of struct values is hardly advised (
https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx)
And I would be surprised if the Dart VM team (especially Lars and Gilad)
liked struct values. They complicate the language and require (I guess)
static type information because they are not like objects.
Besides http://gbracha.blogspot.be/2009/05/original-sin.html
On the other hand, value types might be available in Java 10.
If I understand your idea correctly then you talk about inlined fields.
Can the VM not decide well enough when to inline what ?

Language-wise, I agree. There's nothing we could do with structs that we
can't with regular classes (if we disregard GC pressure).
But performance-wise (#perfmatters was everywhere when Dart was launched),
it's a game-changer.
Since we want to go mobile and IoT, it's quite relevant.
Besides, it would really favor composition, without performance degradation.
I don't think the VM performs this kind of optimizations.
It maybe could stack-allocate a few things.
But I don't think there's enough information/guaranties to inline class
fields inside other classes.
And it's probably impossible if mirrors are used.

[Daniel Joyce]

Optional typing is a copout. It's wasted effort on the language front since
tools and users can just ignore it (making them operate poorly with code
that does have types). It also makes inferencing weaker as well since if
you use a untyped library with your typed code, 'dynamic' will creep into
everything rendering it moot. So then you have provide a typed spec to a
untyped lib to make inferencing work. Kinda like typescript d.ts files. Now
sadly this extra work but at least with typescript I can use thousands of
existing js libraries so the 'gain' from the extra work isn't terribl,
whereas js interop in dart and json support is painful. Also typescript
typing is way more powerful in many areas. They way they handle interfacing
to js methods that say take strings or objects and you specify that in a
d.ts file is easy and quick.

As for dart 'never' replacing js in the browser from the get go was never
the attention. That's hard to believe. Seems to me like saving face. Go was
promised to be a systems language to replace C and then Google backpedaled
on that as well.

Dart js interop needs to massively improve for any traction on the browser.
Looking at how typescript handles typing of js code via union types and
other such features would be a good first step. Anything not easier than
typescript will likely not win in the browser.

Post by Gen
The combination of variables that can not reference null and sealed
classes might help with regard to performance.
But even then value types and a compiler that optimizes based on types
might make sense.
- Dart does not replace Javascript and it was never the goal according to
official sources.
- The top 5 or top 10 programming languages (will) compile to Ecmascript
or web assembly.
- Dart and its optional types do not appeal particularly to either dynamic
nor static type proponents.
What is the programming culture with Dart ? Explicit types, complex API
for engineers, classic compilation, classic tools.
- Dart (and its libraries) is not simple. Professional programming is not
simple. No successful general purpose language is simple. Even Ecmascript
is very large and complex.
I have nothing against more ways that make Dart a valid choice for
whatever purpose. This includes threads and value types if there is no
better alternative.

Post by Filipe Morgado

Post by Gen
I do not know if struct values are that useful.
For .net, the use of struct values is hardly advised (
https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx)
And I would be surprised if the Dart VM team (especially Lars and Gilad)
liked struct values. They complicate the language and require (I guess)
static type information because they are not like objects.
Besides http://gbracha.blogspot.be/2009/05/original-sin.html
On the other hand, value types might be available in Java 10.
If I understand your idea correctly then you talk about inlined fields.
Can the VM not decide well enough when to inline what ?

Language-wise, I agree. There's nothing we could do with structs that we
can't with regular classes (if we disregard GC pressure).
But performance-wise (#perfmatters was everywhere when Dart was
launched), it's a game-changer.
Since we want to go mobile and IoT, it's quite relevant.
Besides, it would really favor composition, without performance degradation.
I don't think the VM performs this kind of optimizations.
It maybe could stack-allocate a few things.
But I don't think there's enough information/guaranties to inline class
fields inside other classes.
And it's probably impossible if mirrors are used.

--
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
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[Warren]

In practice optional typing seems to work quite well.

Most (all?) Dart libraries I have used include type declarations.

Post by Daniel Joyce
Optional typing is a copout. It's wasted effort on the language front
since tools and users can just ignore it (making them operate poorly with
code that does have types). It also makes inferencing weaker as well since
if you use a untyped library with your typed code, 'dynamic' will creep
into everything rendering it moot. So then you have provide a typed spec to
a untyped lib to make inferencing work. Kinda like typescript d.ts files.
Now sadly this extra work but at least with typescript I can use thousands
of existing js libraries so the 'gain' from the extra work isn't terribl,
whereas js interop in dart and json support is painful. Also typescript
typing is way more powerful in many areas. They way they handle interfacing
to js methods that say take strings or objects and you specify that in a
d.ts file is easy and quick.
As for dart 'never' replacing js in the browser from the get go was never
the attention. That's hard to believe. Seems to me like saving face. Go was
promised to be a systems language to replace C and then Google backpedaled
on that as well.
Dart js interop needs to massively improve for any traction on the
browser. Looking at how typescript handles typing of js code via union
types and other such features would be a good first step. Anything not
easier than typescript will likely not win in the browser.

Post by Gen
The combination of variables that can not reference null and sealed
classes might help with regard to performance.
But even then value types and a compiler that optimizes based on types
might make sense.
- Dart does not replace Javascript and it was never the goal according to
official sources.
- The top 5 or top 10 programming languages (will) compile to Ecmascript
or web assembly.
- Dart and its optional types do not appeal particularly to either
dynamic nor static type proponents.
What is the programming culture with Dart ? Explicit types, complex API
for engineers, classic compilation, classic tools.
- Dart (and its libraries) is not simple. Professional programming is not
simple. No successful general purpose language is simple. Even Ecmascript
is very large and complex.
I have nothing against more ways that make Dart a valid choice for
whatever purpose. This includes threads and value types if there is no
better alternative.

Post by Filipe Morgado

Post by Gen
I do not know if struct values are that useful.
For .net, the use of struct values is hardly advised (
https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx)
And I would be surprised if the Dart VM team (especially Lars and
Gilad) liked struct values. They complicate the language and require (I
guess) static type information because they are not like objects.
Besides http://gbracha.blogspot.be/2009/05/original-sin.html
On the other hand, value types might be available in Java 10.
If I understand your idea correctly then you talk about inlined fields.
Can the VM not decide well enough when to inline what ?

Language-wise, I agree. There's nothing we could do with structs that we
can't with regular classes (if we disregard GC pressure).
But performance-wise (#perfmatters was everywhere when Dart was
launched), it's a game-changer.
Since we want to go mobile and IoT, it's quite relevant.
Besides, it would really favor composition, without performance degradation.
I don't think the VM performs this kind of optimizations.
It maybe could stack-allocate a few things.
But I don't think there's enough information/guaranties to inline class
fields inside other classes.
And it's probably impossible if mirrors are used.

--
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
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce
The meek shall inherit the Earth, for the brave will be among the stars.

[kc]

Post by Warren
In practice optional typing seems to work quite well.
Most (all?) Dart libraries I have used include type declarations.

There could be a case for:
- making types on library interfaces mandatory
- a strong type interference story within apps which consume (typed) libs.

Especially if 'dynamic' was replaced with something an shorter like 'Any',
'any' or 'dyn'.

// Dynamic/duck
Any pa = new Point(1,1);

// mutable type inference
var pm = new Point(1,1);

// immutable type inference
let pi = new Point(1,1);

// Explicit type
Point pe = new Point(1,1);



K.

Post by Warren

Post by Daniel Joyce
Optional typing is a copout. It's wasted effort on the language front
since tools and users can just ignore it (making them operate poorly with
code that does have types). It also makes inferencing weaker as well since
if you use a untyped library with your typed code, 'dynamic' will creep
into everything rendering it moot. So then you have provide a typed spec to
a untyped lib to make inferencing work. Kinda like typescript d.ts files.
Now sadly this extra work but at least with typescript I can use thousands
of existing js libraries so the 'gain' from the extra work isn't terribl,
whereas js interop in dart and json support is painful. Also typescript
typing is way more powerful in many areas. They way they handle interfacing
to js methods that say take strings or objects and you specify that in a
d.ts file is easy and quick.
As for dart 'never' replacing js in the browser from the get go was never
the attention. That's hard to believe. Seems to me like saving face. Go was
promised to be a systems language to replace C and then Google backpedaled
on that as well.
Dart js interop needs to massively improve for any traction on the
browser. Looking at how typescript handles typing of js code via union
types and other such features would be a good first step. Anything not
easier than typescript will likely not win in the browser.

Post by Gen
The combination of variables that can not reference null and sealed
classes might help with regard to performance.
But even then value types and a compiler that optimizes based on types
might make sense.
- Dart does not replace Javascript and it was never the goal according
to official sources.
- The top 5 or top 10 programming languages (will) compile to Ecmascript
or web assembly.
- Dart and its optional types do not appeal particularly to either
dynamic nor static type proponents.
What is the programming culture with Dart ? Explicit types, complex API
for engineers, classic compilation, classic tools.
- Dart (and its libraries) is not simple. Professional programming is
not simple. No successful general purpose language is simple. Even
Ecmascript is very large and complex.
I have nothing against more ways that make Dart a valid choice for
whatever purpose. This includes threads and value types if there is no
better alternative.

Post by Filipe Morgado

Post by Gen
I do not know if struct values are that useful.
For .net, the use of struct values is hardly advised (
https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx)
And I would be surprised if the Dart VM team (especially Lars and
Gilad) liked struct values. They complicate the language and require (I
guess) static type information because they are not like objects.
Besides http://gbracha.blogspot.be/2009/05/original-sin.html
On the other hand, value types might be available in Java 10.
If I understand your idea correctly then you talk about inlined fields.
Can the VM not decide well enough when to inline what ?

Language-wise, I agree. There's nothing we could do with structs that
we can't with regular classes (if we disregard GC pressure).
But performance-wise (#perfmatters was everywhere when Dart was
launched), it's a game-changer.
Since we want to go mobile and IoT, it's quite relevant.
Besides, it would really favor composition, without performance degradation.
I don't think the VM performs this kind of optimizations.
It maybe could stack-allocate a few things.
But I don't think there's enough information/guaranties to inline class
fields inside other classes.
And it's probably impossible if mirrors are used.

--
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
To unsubscribe from this group and stop receiving emails from it, send

--
Daniel Joyce
The meek shall inherit the Earth, for the brave will be among the stars.

[kc]

Post by 'Bob Nystrom' via Dart Misc

Post by Filipe Morgado
As I understand it, at every call site, a (slow) dynamic lookup is
performed on the receiver.
Once a type is encountered a sufficient number of times, the call site is
recompiled with an optimized path for that particular type.

Pretty much, yes.

Post by Filipe Morgado
If too many types are encountered, all optimizations are thrown away and
dynamic lookup is always used.

Also true, though it's worth noting that this happens fairly rarely in
practice. Even in completely dynamically typed languages, any given code
path often tends to work with only one or two concrete types in practice.
This, to me, is one of the big insights of static typing—it takes that
insight and then says "Well, if we take as a given that variable types do
*tend* to be static, and we go a bit farther and *require* that, what can
we get in return?" It turns out to be a hell of a lot: better static
tooling, a better IDE experience, better performance, better memory usage,
fewer bugs, etc.
I believe as well that it is this way so the DartVM doesn't have to

Post by Filipe Morgado
perform complicated type inference and/or analysis and have fast startup
times.

It's not just about type inference and startup time. Because the type
system is (wildly) unsound, even if we did all the inference in the world,
the VM still has to handle cases where the type analysis was wrong and
something fell through a hole in the type system.

Post by Filipe Morgado
But we end up with type checks all over the place and, sometimes maybe,
slow optimization/deoptimization cycles.
With a sound static type system, I think we could have 3 types of method
- Direct. We know a given instance is of a particular type, it wasn't
extended nor mixed in.
We call the method directly and may even inline it (provided we know
it's not null, NNBD ftw).
I believe most calls fall in this category.

1. A closed world assumption, i.e. whole program analysis. You need to
be able to see all of the classes in the entire program to tell if a given
method has been overridden or not. That tends to be slower and makes things
like dynamic loading harder.
2. Final or sealed classes. A way to say, "You know this method will
not be overridden because I am *declaring* that the class may not be
subclassed (or have its implicit interface implemented)."
3. Nonvirtual or final methods. Sort of the more fine-grained approach
to #2. A way to say, "I am declaring that this method may not be
overridden."
With one of those, you're able to statically tell if a given invocation
will always invoke a known method.

Post by Filipe Morgado
- vTable. We know the type implements a given interface. The type
provides a method table for that interface.
We call the method through one single indirection (provided we
efficiently get that table and the instance is not null, NNBD ftw).
I believe most polymorphic calls fall in this category.
Yup. This is basically Go's approach. Go gives you some of the feel of

dynamic typing by being structurally typed. But every "dynamic" invocation
is always through some known interface type.

Post by Filipe Morgado
- Dynamic. We don't know the exact type so the call site behaves as
currently implemented (and explained above).
With union types, I believe dynamism would be used very rarely,
mostly when dealing with external sources such as Json.
Yes. I like C#'s approach here, which is that "dynamic" is a special type

sort of on the side of the rest of the type system. A variable who's type
is "dynamic" kind of reinterprets the invocation syntax to mean something
else, more like a property lookup.

Post by Filipe Morgado
We should pay the price of dynamism and/or polymorphism only when we
actually need it.

With the VM, this is actually more or less true, at least when it comes to
method dispatch. The VM is really good at optimizing this stuff.
1. Places where we need to statically compile Dart and care about the
resulting code size: dart2js.
2. Places where we cannot run a JIT: iOS.
3. Memory usage and the performance implications of it.
The last one, I think, may be the biggest performance hit for us. Not
having rigidly statically typed fields and local variables makes it harder
to allocate objects on the stack or in place inside an instance. You end up
with Java's model where you have a huge cloud of little objects with tons
of references between them. All of that indirection is really hard on cache
and memory usage.
I believe this is a strong argument for sound static types and fully

Post by Filipe Morgado
annotated/inferred/optimized Dart programs.

+1.
If you look at all of the languages that are widely used on client
devices, they are almost all statically typed: C/C++ (embedded, game
consoles, lots of mobile apps), Java (Android), Swift (iOS).
Objective-C is an interesting outlier because it has dynamic dispatch, but
a big part of it is the ability to opt *out* of that and drop down to
bare C semantics. Performance critical code like physics engines invariably
do that.

Dart has the most semantic similarity to Objective C - and the Objective C
runtime was fast enough - and also powerful and flexible.

Re the 'C' part - my question is if Dart gets 'value objects' - like
Project Valhalla in Java - could it get enough to a performance boost to
compete with say ART on Android.

http://openjdk.java.net/jeps/169

K.

Post by 'Bob Nystrom' via Dart Misc
Cheers!
– bob

['Kevin Millikin' via Dart Misc]

Post by Filipe Morgado
As I understand it, at every call site, a (slow) dynamic lookup is
performed on the receiver.
Once a type is encountered a sufficient number of times, the call site is
recompiled with an optimized path for that particular type.

That's not accurate. In unoptimized code every call site is associated
with its own inline cache (IC). The IC records classes and target
methods. It is searched via linear search by a small loop of assembly
code. Only in the event of a cache miss is a full dynamic lookup through
the runtime performed, and the result added to the cache.

Post by Filipe Morgado
If too many types are encountered, all optimizations are thrown away and
dynamic lookup is always used.

That's also not accurate. If the degree of polymorphism is too high
(currently, greater than 4) in optimized code then there is a "megamorphic"
IC. This is a hash table associated with the call site, with classes as
keys and target methods as values. The hash table is probed by a small
loop of assembly code. Only in the event of a cache miss is a full dynamic
lookup performed, and the result added to the cache.

[kc]

Post by 'Kevin Millikin' via Dart Misc

Post by Filipe Morgado
As I understand it, at every call site, a (slow) dynamic lookup is
performed on the receiver.
Once a type is encountered a sufficient number of times, the call site is
recompiled with an optimized path for that particular type.

That's not accurate. In unoptimized code every call site is associated
with its own inline cache (IC). The IC records classes and target
methods. It is searched via linear search by a small loop of assembly
code. Only in the event of a cache miss is a full dynamic lookup through
the runtime performed, and the result added to the cache.

Post by Filipe Morgado
If too many types are encountered, all optimizations are thrown away and
dynamic lookup is always used.

That's also not accurate. If the degree of polymorphism is too high
(currently, greater than 4) in optimized code then there is a "megamorphic"
IC. This is a hash table associated with the call site, with classes as
keys and target methods as values. The hash table is probed by a small
loop of assembly code. Only in the event of a cache miss is a full dynamic
lookup performed, and the result added to the cache.

This approach sounds flexible and powerful. But is it good enough for
mobile re performance and resource usage (mem/cpu/battery) - especially
compared to ART on Android.

Would 'value objects' help performance.

Is a more static 'vtable' needed?

K.

[Filipe Morgado]

I would even go further and propose to completely abstract polymorphism
away when not needed.

The gain may not be as big as expect in Dart, considering there are
multiple internal representations of num, String, etc ...

But might still be significant in some contexts, and developers could
opt-out if it was well understood when polymorphism kicks-in.

To avoid the need for a complex code analysis, we could introduce a
keyword/character to indicate that we do not want polymorphism.

I'm using '!' as an example to indicate that a type must be exactly that
type and not anything else, not extended, not mixed-in, not implemented,
not even Null.
(It conflicts with the NNBD proposal, but you get the point).

class Sprite {
// A non-nullable reference to a Point, and exactly a Point
final Point! position = new Point(0, 0);

// A nullable reference to a Point, and exactly a Point
Point!? pivot = null;

// A non-nullable polymorphic reference to a point
Point p1 = new Point(0, 0);

// A nullable polymorphic reference to a point
Point? p2 = null;

// A non-nullable Bool, and exactly a Bool.
// Most bools are used this way. Are we missing optimization
opportunities?
bool! visible = true;
}

On a side-note, the combination of '!' and final may give enough
information to inline the Point's structure inside Sprite.

Post by kc

Post by 'Kevin Millikin' via Dart Misc

Post by Filipe Morgado
As I understand it, at every call site, a (slow) dynamic lookup is
performed on the receiver.
Once a type is encountered a sufficient number of times, the call site
is recompiled with an optimized path for that particular type.

That's not accurate. In unoptimized code every call site is associated
with its own inline cache (IC). The IC records classes and target
methods. It is searched via linear search by a small loop of assembly
code. Only in the event of a cache miss is a full dynamic lookup through
the runtime performed, and the result added to the cache.

Post by Filipe Morgado
If too many types are encountered, all optimizations are thrown away and
dynamic lookup is always used.

That's also not accurate. If the degree of polymorphism is too high
(currently, greater than 4) in optimized code then there is a "megamorphic"
IC. This is a hash table associated with the call site, with classes as
keys and target methods as values. The hash table is probed by a small
loop of assembly code. Only in the event of a cache miss is a full dynamic
lookup performed, and the result added to the cache.

This approach sounds flexible and powerful. But is it good enough for
mobile re performance and resource usage (mem/cpu/battery) - especially
compared to ART on Android.
Would 'value objects' help performance.
Is a more static 'vtable' needed?
K.

[Gen]

I use types everywhere.
Dart's type system and type inference gives much liberty and comfort.

I hope that Dart will get a set of efficient integer and floating point
types
because I like to know that I have a list of bytes (e.g. for dart:io) and
not a list of arbitrary integers.

Should the Dart VM ever replace the Java VM for Android then it is probably
fortunate that Dart is a good platform for most or all languages and not
just statically typed languages.
But I do not know how far the Dart VM can approach C++ or even the Java VM
with regard to performance and power efficiency.
It would be nice if statically typed Dart programs would run as efficiently
as Java programs or could be even statically compiled and optimized like
C++ or Swing.

Post by kc

Post by Filipe Morgado
Personally, I like static type systems. I just don't like having to write
types everywhere to get reasonable analysis.

I find any coding done in service of the type system to be mostly wasted
effort when writing high-level code

If a function takes a String argument, I wanna be sure it can only be
passed a String, not anything else, not even null (unless I specify it).
And Dart with static (sound) typing would be much easier to compile
natively (hello iOS).
I can't comment on how it is to work with Swift, but it does seems
interesting.
I do like Ceylon, but I'm not a fan of JVM environments.
Bob mentioned that, since initial design considerations had changed, they
could break the s*** out of the language and the platform.
He even mentioned that the DartVM could become a bytecode VM which runs
fully-annotated binary ASTs (independently of language changes).
WebAssembly showed good preliminary results on this concept.
I do hope it goes this way.
Flash was pretty good (still is for me) as some benchmarks show
<https://github.com/joelgwebber/bench2d>. We can even run C/C++ on it.
I don't think we can get this kind of performance with dynamic
languages (as in "not fully inferred").
Most code doesn't even need polymorphism, why not optimize it away?
Something to consider since we want to target mobile and IoT.
Well, my 2 cts. :P

Right. There was a 'theory' to Dart 1.x and the VM - types are
documentation - so it will be interesting if the Dart team go in another
direction.
Value objects seem to be the missing middle between standard reference
objects and 'const' objects.
My question is with Value objects and maybe privileging core numeric types
like 'double' could you get much of the perf benefits and keep some
flexibility.
Personally for numeric/algorithmic/money code I want max static type
checks. But for higher-level code the dynamic/simulation aspect of objects
works well.
K.

[George Moschovitis]

Post by Gen
I hope that Dart will get a set of efficient integer and floating point
types
because I like to know that I have a list of bytes (e.g. for dart:io) and
not a list of arbitrary integers.

+1

[kc]

Post by Filipe Morgado
Personally, I like static type systems. I just don't like having to write
types everywhere to get reasonable analysis.

I find any coding done in service of the type system to be mostly wasted
effort when writing high-level code

If a function takes a String argument, I wanna be sure it can only be
passed a String, not anything else, not even null (unless I specify it).
And Dart with static (sound) typing would be much easier to compile
natively (hello iOS).
I can't comment on how it is to work with Swift, but it does seems
interesting.
I do like Ceylon, but I'm not a fan of JVM environments.
Bob mentioned that, since initial design considerations had changed, they
could break the s*** out of the language and the platform.
He even mentioned that the DartVM could become a bytecode VM which runs
fully-annotated binary ASTs (independently of language changes).
WebAssembly showed good preliminary results on this concept.
I do hope it goes this way.

Maybe Dart could leverage the wasm AST spec/format at a higher level. Or
protobufs 2, flatbuffers? No need to reinvent the wheel.

K.