Notes from June 10th language meeting

[Bob Nystrom]

Here's my notes from this week's (short) meeting:

Name collisions with dart: imports

[A customer recently ran into an issue where a new type appeared in dart:html whose name collided with a name they were importing from elsewhere. This broke their app.]

Gilad brought up this issue. Pete's suggestion is if there's a collision between a "dart:" import and another library, the other library wins. That way, we can add stuff to "dart:" libraries without breaking people. I explained some more details here.

Lars asked if there are any negative consequences from that suggestion and when it needs to be fixed. Kasper suggested we start making it a warning [instead of an error?] now.

Ivan asked how JS handles this. Kasper said DOM names are usually higher up on the prototype chain so you get similar shadowing behavior there to what we're suggesting for Dart now.

Type guards

Folks in Aarhus had a discussion about type guards. When you do "if (x is Foo)" in the then branch can you statically tell x is of type Foo? The conclusion they came to is that if locals aren't final, the rules are so complicated it's not worth doing. With mutable locals, you get lots of problems with closures that assign to that local.

For finals, though, they are fine with inferring the type here as long as it doesn't make the rules too weird.

I asked about parameters which are non-final by default. Kasper says you can mark those final.

Cheers!

- bob

[Cogman]

How does dart handle different libraries depending on different versions of a shared library? This is a pretty big issue in the java world (see project Jigsaw as a stab at managing the issue).

--
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
 
 

[Bob Nystrom]

On Thu, Jun 13, 2013 at 10:55 AM, mezoni <andrew...@gmail.com> wrote:

Is this question about static single assignment form (SSA form) based code analyzing or about something other?

Right now, the language specifies that this program must display a static type warning when you analyze it:

foo(Object arg) {

  if (arg is String) print(arg.length);

}

By "can you statically tell", Lars meant "should we extend the static type checker to be able to tell" that this there should be no type warning here.

Cheers,

- bob

[Bob Nystrom]

On Thu, Jun 13, 2013 at 10:58 AM, Cogman <cog...@gmail.com> wrote:

How does dart handle different libraries depending on different versions of a shared library? This is a pretty big issue in the java world (see project Jigsaw as a stab at managing the issue).

This is handled by the package manager. It uses a model similar to Bundler for Ruby where packages depend on a range of versions and the package manager selects a single version that satisfies all constraints.

Cheers!

- bob

[Cogman]

> This is handled by the package manager. It uses a model similar to Bundler for Ruby where packages depend on a range of versions and the package manager selects a single version that satisfies all constraints.

Java has something similar to this (maven), however, that doesn't always fit the bill.  For example, what if one library depends on version 1.5 of a package, that package deprecates function x for y in 1.7 and in 1.9 function x is removed and replaced by y.  Then another package depends on version 1.9 and uses function y.

Now, imagine you don't have control of either of those libraries.

These are issues that simply relying on a package manager won't fix.  They don't happen often in smaller project, however, very large project run into them quite frequently.

--

[Bob Nystrom]

On Thu, Jun 13, 2013 at 11:52 AM, Cogman <cog...@gmail.com> wrote:

Java has something similar to this (maven), however, that doesn't always fit the bill.  For example, what if one library depends on version 1.5 of a package, that package deprecates function x for y in 1.7 and in 1.9 function x is removed and replaced by y.  Then another package depends on version 1.9 and uses function y.

Now, imagine you don't have control of either of those libraries.

Code reuse is hard.

Semantic versioning and constraint solving over version ranges make it a lot easier to reuse code that is quickly evolving but there's no silver bullet.

- bob

[Greg Lowe]

> if (x is Foo) { ... }

In a majority of cases even when x is not final it won't be reassigned inside the block, and a reference to it won't escape the scope. Is it possible to handle the simple cases, and give up whenever x is reassigned or escapes the scope? I assume it's not worth putting that in the language spec as it's too complicated to specify. But it would still be useful feedback when writing code, and something that could be put in the analyser.

Also, in the editor, it would still be a net win to get completions based on Foo, even if it's correct only 99% of the time. But that's a separate issue for the editor folks I guess.

[Brian Wilkerson]

Greg,

> if (x is Foo) { ... }

In a majority of cases even when x is not final it won't be reassigned inside the block, and a reference to it won't escape the scope. Is it possible to handle the simple cases, and give up whenever x is reassigned or escapes the scope? I assume it's not worth putting that in the language spec as it's too complicated to specify. But it would still be useful feedback when writing code, and something that could be put in the analyser.

That kind of logic is already in the analyzer. The question before the language committee is whether to expand the specification to include (possibly a subset of) this logic and to use that logic to control the generation of errors and warnings. It's fairly easy to define in the variable is final because the value can't change. For non-final local variables you could determine whether the variable is captured by a closure (though I'm not sure I'd want to have to write that part of the spec :-). It's even possible to deal with local variables that are re-assigned, as long as they're not captured, by limiting the scope of where you can assume you know the type. For non-final fields and top-level variables, though, it's pretty much hopeless. I think the question is whether it's worth the complexity in the specification in order to get rid of some errors and warnings.

Also, in the editor, it would still be a net win to get completions based on Foo, even if it's correct only 99% of the time. But that's a separate issue for the editor folks I guess.

Code completion, refactorings, and other tools within Editor already make use of this information and will continue to do so. The only real question is whether to specify this logic.

Brian

[Greg Lowe]

Thanks for the extra info Brian. Good to hear that the Editor already does this inference.

I understand that this shouldn't be added to the spec due to it's complexity. Is it fair to say that in some cases the dart analyzer could provide more useful warnings to the user by not following the spec exactly? This seems to be one of those cases.

--

[Colin Putney]

On Thu, Jun 13, 2013 at 3:21 PM, Brian Wilkerson <brianwi...@google.com> wrote:

 

Code completion, refactorings, and other tools within Editor already make use of this information and will continue to do so. The only real question is whether to specify this logic.

Would it make sense to specify some guidelines for going beyond the spec? For example, perhaps the spec could define something called a "note" and just mention that if a tool can statically prove that the value of a variable won't change it may generate a note instead of a warning. It's up to tool-makers to figure out how to do the proof, but if they do, they have a standard vocabulary for communicating with the user.

Colin

[Brian Wilkerson]

Greg and Colin,

 

Is it fair to say that in some cases the dart analyzer could provide more useful warnings to the user by not following the spec exactly?

Would it make sense to specify some guidelines for going beyond the spec?

Those are both good questions. Both suggestions make sense to me :-), but we'll see what the language committee has to say about the issue.

We can create (what we're tentatively referring to as) suggestions that are in addition to what the specification dictates (as long as users don't see them unless they want them), but we can't suppress errors and warnings that are required by the spec., so getting the spec. changed is the only way to get rid of this class of errors.

Brian

[Bob Nystrom]

On Thu, Jun 13, 2013 at 3:21 PM, Brian Wilkerson <brianwi...@google.com> wrote:

It's fairly easy to define in the variable is final because the value can't change. For non-final local variables you could determine whether the variable is captured by a closure (though I'm not sure I'd want to have to write that part of the spec :-).

An easier approximation would be extend it to support "effectively final" variables that aren't marked final but are still never assigned to outside of their initializers. I could be wrong, but I believe most local variables, especially parameters, fit in that bucket.

 

It's even possible to deal with local variables that are re-assigned, as long as they're not captured, by limiting the scope of where you can assume you know the type.

That would be nice too!

 

For non-final fields and top-level variables, though, it's pretty much hopeless.

I think those are less of a concern: from code I've seen, fields and top-level variables are much more likely to already have precise type annotations. It's mostly locals and parameters that are either untyped or where a user is doing a "checked" downcast.

 

I think the question is whether it's worth the complexity in the specification in order to get rid of some errors and warnings.

I feel that it is. The language designers have put a lot of work into not showing false positive warnings to the user. It seems consistent with that work to do some basic analysis here too. Otherwise, most places that use an "is" check will generate erroneous warnings.

Cheers,

- bob

[Justin Fagnani]

I question whether this belongs in the core spec though. The issue with the editor was that it added warnings not in the spec and suppressed some warnings that are in the spec. It sounds like it was decided that the editor could add warnings as separate "suggestions", but couldn't surpress warnings, and therefore we need to consider smarter warning logic in the spec.

This seems like the wrong approach. I'd rather see absolutely no warnings in the spec at all, just errors. Then see a separate specification for standard warnings that includes provisions for allowing a type checker to add and surpress warnings when it deems appropriate.

-Justin

 

Cheers,

- bob