last changes in analyzer

[Alexandre Ardhuin]

Hi all,

The last two release of Dart Editor brought some changes (on type handling) in Dart Analyzer that makes me really sad. The 2 main concerns are :

1. Now (in Dart Editor version 0.6.21_r26639) I have to explicitly indicate the type of a variable

      String s1 = '';
      s1.wtf; // a warning appears
      final s2 = '';
      s2.wtf; // no warning here !!!!

If I understand correctly, s2 is now handled as dynamic. That means that any change on the type of s2 will not produce warning.

I have almost always used this second form of variable's declaration in all my codes and it will be really hard to modify all the declarations. But if I don't make that change I will not be able to get warnings if some methods change or go away

2. http://dartbug.com/12651

    class MyBase {
    }
   
    class MySub extends MyBase {
      int x = 0;
    }
   
    void main() {
      MyBase o = new MySub();
      if (o is MySub && o.x > 0) { // warning on o.x although it is a MySub
      }
    }

The first point is really REALLY annoying (I think many people will be affected by this change) and I can't imagine the amount of work to add types everywhere :-(

Cheers

Alexandre

[Brian Wilkerson]

Alexandre,

The editor team has plans to add "hints" for problems that can be detected by using propagated type information, which should address your first concern. I don't have a time frame for when this will happen, but this is likely to be one of the next hints that we add, so I'm hoping we'll be able to add it fairly soon.

We can't really do anything about the second issue because we need to conform to the specification.

Brian

--
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 email to misc+uns...@dartlang.org.

[Eric Clayberg (Google)]

As Brian noted, we are allowed to add additional Hints that go beyond the errors and warnings in the spec, so we do plan to address #1 very soon. 

#2 is problematic because "doing the right thing" (as we did in the past) means suppressing a valid warning from the spec. While we can't do that by default as the default must conform to the spec, we have discussed whether we should add a user option to use type inference to actually suppress spec warnings in cases of apparent false positives like #2. We certainly can do it and have the code to do (as evidenced by the older behavior), but we have not yet answered the question of whether we should do it. There is much ongoing debate on that topic.

-Eric

[Bob Nystrom]

On Tue, Aug 27, 2013 at 9:08 AM, Eric Clayberg (Google) <clay...@google.com> wrote:

As Brian noted, we are allowed to add additional Hints that go beyond the errors and warnings in the spec, so we do plan to address #1 very soon. 

Is there a tracking bug for this so that we can star it and gauge user demand here?

Likewise, is there a bug for not showing warnings in cases where inference makes it obvious that they are invalid? Getting a warning in code like:

var foo = ...

if (foo is String) foo.length;

Doesn't add any value to the life of any Dart user on Earth.

- bob

[Justin Fagnani]

On Tue, Aug 27, 2013 at 9:08 AM, Eric Clayberg (Google) <clay...@google.com> wrote:

As Brian noted, we are allowed to add additional Hints that go beyond the errors and warnings in the spec, so we do plan to address #1 very soon. 

#2 is problematic because "doing the right thing" (as we did in the past) means suppressing a valid warning from the spec. While we can't do that by default as the default must conform to the spec, we have discussed whether we should add a user option to use type inference to actually suppress spec warnings in cases of apparent false positives like #2. We certainly can do it and have the code to do (as evidenced by the older behavior), but we have not yet answered the question of whether we should do it. There is much ongoing debate on that topic.

IMO, in order to provide a decent user experience we have to suppress some of these warnings when we can. They make Dart either feel less like a dynamic language because of the casts and reassignments required, or encourage everything to be untyped. I've already seen cases where warnings are just being ignored because there are too many of them.

-Justin

 

-Eric

On Tuesday, August 27, 2013 9:26:00 AM UTC-4, Alexandre Ardhuin wrote:

Hi all,

The last two release of Dart Editor brought some changes (on type handling) in Dart Analyzer that makes me really sad. The 2 main concerns are :

1. Now (in Dart Editor version 0.6.21_r26639) I have to explicitly indicate the type of a variable

      String s1 = '';
      s1.wtf; // a warning appears
      final s2 = '';
      s2.wtf; // no warning here !!!!

If I understand correctly, s2 is now handled as dynamic. That means that any change on the type of s2 will not produce warning.

I have almost always used this second form of variable's declaration in all my codes and it will be really hard to modify all the declarations. But if I don't make that change I will not be able to get warnings if some methods change or go away

2. http://dartbug.com/12651

    class MyBase {
    }
   
    class MySub extends MyBase {
      int x = 0;
    }
   
    void main() {
      MyBase o = new MySub();
      if (o is MySub && o.x > 0) { // warning on o.x although it is a MySub
      }
    }

The first point is really REALLY annoying (I think many people will be affected by this change) and I can't imagine the amount of work to add types everywhere :-(

Cheers

Alexandre

--

[Brian Wilkerson]

Bob,

As Brian noted, we are allowed to add additional Hints that go beyond the errors and warnings in the spec, so we do plan to address #1 very soon. 

Is there a tracking bug for this so that we can star it and gauge user demand here?

Not really, no.

Likewise, is there a bug for not showing warnings in cases where inference makes it obvious that they are invalid?

No, I have been closing such issues as "As Designed". I really think this is an ecosystem issue. The current decision is that tools (at least the ones that we're producing) cannot suppress errors and warnings from the specification. I agree that some (it would be interesting to know what percentage) of these errors are not helpful and that it would be nice to remove the ones we can (another interesting number).

But I also agree that it's important that either the tools are consistent (one of the main reasons for the current decision) or that it's clear to the user why the results are different. There has been considerable confusion when editor, dart2js and the VM don't agree about which errors and warnings to report, which is also not good for users.

Brian

[Bob Nystrom]

On Tue, Aug 27, 2013 at 10:12 AM, Brian Wilkerson <brianwi...@google.com> wrote:

Not really, no.

OK, filed one then: https://code.google.com/p/dart/issues/detail?id=12818

I am really excited about the analyzer showing hints and I'd like to make sure it gets tracked. :)

Also, I filed another bug about giving the analyzer a way to indicate which warnings are false positives: https://code.google.com/p/dart/issues/detail?id=12821

Cheers!

- bob

[Eric Clayberg (Google)]

Is there a tracking bug for this so that we can star it and gauge user demand here?

I see you added one. Good! We plan to do that one soon. :-)

 

Likewise, is there a bug for not showing warnings in cases where inference makes it obvious that they are invalid?

I see you added that one too. Even better! :-) I really like the idea of issuing the warnings per the spec but then decorating them in a different way (maybe use a hollow icon or a small green check overlay) to indicate they are a false positives.

 

Getting a warning in code like:

var foo = ...

if (foo is String) foo.length;

Doesn't add any value to the life of any Dart user on Earth.

I completely agree and was very sad when we had to stop suppressing warnings like that. We actually identified quite a few use cases like the above where we could suppress false positives.

 

[John Messerly]

On Tue, Aug 27, 2013 at 7:49 AM, Brian Wilkerson <brianwi...@google.com> wrote:

Alexandre,

The editor team has plans to add "hints" for problems that can be detected by using propagated type information, which should address your first concern. I don't have a time frame for when this will happen, but this is likely to be one of the next hints that we add, so I'm hoping we'll be able to add it fairly soon.

question: are these hints only for "final" or do they work for "var" as well?

(I vaguely recall some language team notes that seemed open to the possibility of local type propagation for "final" variables.)

[Brian Wilkerson]

John,

The editor team has plans to add "hints" for problems that can be detected by using propagated type information, which should address your first concern. I don't have a time frame for when this will happen, but this is likely to be one of the next hints that we add, so I'm hoping we'll be able to add it fairly soon.

question: are these hints only for "final" or do they work for "var" as well?

They will be anywhere where we can correctly propagate type information, which means for "var" as well as long as the local variable isn't used in a closure in a way that would potentially invalidate type propagation.

Brian

[Bob Nystrom]

On Tue, Aug 27, 2013 at 1:43 PM, Brian Wilkerson <brianwi...@google.com> wrote:

They will be anywhere where we can correctly propagate type information, which means for "var" as well as long as the local variable isn't used in a closure in a way that would potentially invalidate type propagation.

\o/

- bob

[Jonathan Edwards]

This is language lawyer insanity! Displaying proven false positives is a big usability loss.

 

Have a setting in the editor to suppress warnings that it knows are false. And set it by default.

You say there is much ongoing debate on the topic. Can you explain what the argument for false positives is? 

[Gilad Bracha]

Hi Jonathan,

On Wed, Aug 28, 2013 at 2:49 AM, Jonathan Edwards <jonathan...@gmail.com> wrote:

This is language lawyer insanity!

No it isn't. Please avoid abuse in any messages you wish me to respond to. (By abuse, I mean "language lawyer" at least as much as I mean "insanity").

 

Displaying proven false positives is a big usability loss. 

 

Have a setting in the editor to suppress warnings that it knows are false. And set it by default.

You say there is much ongoing debate on the topic. Can you explain what the argument for false positives is? 

Anyone can cite specific examples of false warnings, but a language needs general rules. It is difficult to specify what the rules that exclude such cases are.  Otherwise they would already be excluded by the language spec.  

Given that the warnings are mandated by the spec, all implementations must report them.  It is undesirable if each tool implements its own heuristics. We do not want a program developed without warnings on one tool to cause warnings on another.

This behavior is by know means unusual or unique to Dart. It is easy to show examples where one can see that a complaint given by a compiler is unwarranted in any statically typed language.

What Dart has done is raise the bar for user expectations.  In a normal statically typed language, you are forced to restructure code to the compiler's satisfaction. With the introduction of optional typing, people are demanding more than they have ever asked from conventional type systems. Since they can run the code despite the warnings, they see no reason to change the code; they want the warnings to either be undeniably valid or go away. 

The question then is whether we can accommodate these expectations and how. The proposal should be looked at in that light.  We have debated the question of how to silence spurious warnings since day 1.  We do have to agree on a mechanism for handling this, but there are other possibilities than this specific proposal.

 

On Tuesday, August 27, 2013 12:08:45 PM UTC-4, Eric Clayberg (Google) wrote:

As Brian noted, we are allowed to add additional Hints that go beyond the errors and warnings in the spec, so we do plan to address #1 very soon. 

#2 is problematic because "doing the right thing" (as we did in the past) means suppressing a valid warning from the spec. While we can't do that by default as the default must conform to the spec, we have discussed whether we should add a user option to use type inference to actually suppress spec warnings in cases of apparent false positives like #2. We certainly can do it and have the code to do (as evidenced by the older behavior), but we have not yet answered the question of whether we should do it. There is much ongoing debate on that topic.

-Eric

On Tuesday, August 27, 2013 9:26:00 AM UTC-4, Alexandre Ardhuin wrote:

Hi all,

The last two release of Dart Editor brought some changes (on type handling) in Dart Analyzer that makes me really sad. The 2 main concerns are :

1. Now (in Dart Editor version 0.6.21_r26639) I have to explicitly indicate the type of a variable

      String s1 = '';
      s1.wtf; // a warning appears
      final s2 = '';
      s2.wtf; // no warning here !!!!

If I understand correctly, s2 is now handled as dynamic. That means that any change on the type of s2 will not produce warning.

I have almost always used this second form of variable's declaration in all my codes and it will be really hard to modify all the declarations. But if I don't make that change I will not be able to get warnings if some methods change or go away

2. http://dartbug.com/12651

    class MyBase {
    }
   
    class MySub extends MyBase {
      int x = 0;
    }
   
    void main() {
      MyBase o = new MySub();
      if (o is MySub && o.x > 0) { // warning on o.x although it is a MySub
      }
    }

The first point is really REALLY annoying (I think many people will be affected by this change) and I can't imagine the amount of work to add types everywhere :-(

Cheers

Alexandre

--

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 email to misc+uns...@dartlang.org.

--
Cheers, Gilad

[Jonathan Edwards]

Gilad,

I apologize for raising my voice. After many months of happily coding in Dart this is the first thing that made me angry.

On Wed, Aug 28, 2013 at 6:33 AM, Gilad Bracha <gbr...@google.com> wrote:

Given that the warnings are mandated by the spec, all implementations must report them.  It is undesirable if each tool implements its own heuristics. We do not want a program developed without warnings on one tool to cause warnings on another.

But Gilad, you invented pluggable type systems! Now you seem to be saying that no tools can be smarter than the spec. But specs must be precise and simple and stable, and so can't be smart and evolving. This is a straightjacket that would be unfortunate to impose on the programmer experience in the editor.

You are concerned with inconsistent warnings between multiple (hypothetical future) tools. There are several ways to deal with this:

1) Add a standard-compliant-warnings option to the editor for these use cases.

2) Have these tools use the same analyzer as the editor.

3) Optionally tell the tools to ignore warnings. They are warnings after all. There is one major tool that does exactly this: the Dart VM! Maybe this hypothetical tool can also do its work regardless of compiler warnings.

Can we at least agree that forcing the editor to disable type inferencing hurts programmer usability? It hurts for me. I want my IDE to be as smart as possible. Balanced against that are these tool consistency issues. Can't we compromise by adding an option to the editor to force spec-compliant warnings?

Regards,

Jonathan

[Gilad Bracha]

Hi Jonathan,

We *do* want the tool to provide a good user experience and we *are* thinking about alternatives in that space. There is an inherent tension between the desire for consistency and giving tools maximal freedom. Both improve user experience in some ways.

My *personal* view is that the type system really should be external to the language and entirely managed by tools. In Dart we chose differently - the type system interacts with the runtime in checked mode and this has important benefits and some drawbacks. Dart does not really support pluggable types - it's only taken 20 years to get optional types, so stay tuned ....  

Also, I note that alternate tools are not merely hypothetical. Not everyone uses the Dart Editor - some use other environments, some just use text editors.

Finally, some ideas on how to deal better with the spurious warnings issue.

1. If the tool can prove that a variable has a more specific type than is written, it can refactor the code accordingly - change the declared type, assign to an intermediate variable etc. It should offer to do so.

2. If we agree on annotations that silence the type checker, the tool can offer to insert them if it knows that they are false positives.

You can have a mode that does this for you automatically.  The key difference is that your source base is now guaranteed to work correctly in any tool chain. This is immensely important in the medium and long term, even if people overlook it in the short term.

--
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 email to misc+uns...@dartlang.org.

--
Cheers, Gilad

[Jonathan Edwards]

Gilad,

Could you give a concrete example of the problem you are avoiding? We are talking about warnings. Tools should be tolerant of warnings. Specifically these are type warnings in an optionally typed language, so the tools already know how to deal with untyped variables. My limited imagination is failing to see a big problem worth the cost of hobbling type inference in the editor.

Jonathan

[Eric Clayberg (Google)]

Gilad,

 

Anyone can cite specific examples of false warnings

Very true. We came up with a nice list of rules based on type inference that either identified false warnings that should be suppressed or additional warnings that should be reported. As a benefit to the user, we implemented those rules first in dartc and then in the new analyzer. Both cases that Alexandre identified above (as well as many others) were covered, and users of the Editor were very happy with that. 

In order to be truly spec compliant, we implemented "strict" mode which effectively turned off those rules. The result has been a great many unhappy users (like Alexandre), so we would like to find a way to "fix" the situation - either through the tooling or the spec.

We can address Alexandre's first example easily enough through adding back in new hints which are, in effect, quasi-warnings. Alexandre's second example is more problematic because, in order to address it, we would need to actually suppress a spec compliant warning. We are currently exploring options for reporting the warning but also acknowledging to the user that we know it is a false positive.

It is difficult to specify what the rules that exclude such cases are.

Why (and I am asking a sincere question here)? We came up with several rules that seemed to be very clear cut and obvious (but I am not a language designer, so I am clearly not aware of all of the nuances).

 

 Otherwise they would already be excluded by the language spec.

That would indeed be the ideal solution.

 

Given that the warnings are mandated by the spec, all implementations must report them.

I can understand that and even agree with that. That said, when must we refrain from helping the user beyond that point? Assuming that the default mode is "strict", and we report all errors and warnings according to the spec, can we:

• Offer a user opt-in mode to suppress the display of specific warnings that we know are false positives based on type inference? While this is certainly what we would prefer to do, I believe the answer to that has been a "no" so far.
  
  
• Show the warnings but annotate them in a way that acknowledges to the user that we know they are false positives? We have not been told that we can't do this, so we are exploring alternatives along these lines.

 It is undesirable if each tool implements its own heuristics. We do not want a program developed without warnings on one tool to cause warnings on another.

Agreed. This is the main argument that resulted in our implementation of "strict" mode within the Editor. We were suppressing warnings in the Editor that were then showing up elsewhere in the tool chain. 

Ideally, we should come up with a set of agreed upon heuristics (it could be a small set of very obvious cases to start) and then have all of the tools implement them. Codifying them in the spec would be even better.

 

This behavior is by no means unusual or unique to Dart. It is easy to show examples where one can see that a complaint given by a compiler is unwarranted in any statically typed language.

Good! I would hope that in the case of Dart, we could address some of those cases via the spec or the tools.

 

What Dart has done is raise the bar for user expectations.  In a normal statically typed language, you are forced to restructure code to the compiler's satisfaction. With the introduction of optional typing, people are demanding more than they have ever asked from conventional type systems. Since they can run the code despite the warnings, they see no reason to change the code; they want the warnings to either be undeniably valid or go away. 

Which is exactly the point of this thread! :-)

 

The question then is whether we can accommodate these expectations and how.

I certainly believe that we can... and up until recently, we were being very proactive about doing just that.

The proposal should be looked at in that light.  We have debated the question of how to silence spurious warnings since day 1.

While it may have been naive or presumptuous on our part, the approach taken by dartc and again by the new analyzer was to silence them by suppressing them. The list of rules that we implemented was actually quite short and covered most of the obvious cases that users have pointed out. We also use those same rules to improve the list of code completion choices we present.

 We do have to agree on a mechanism for handling this, but there are other possibilities than this specific proposal.

We should decide on something in that case. Doing nothing at this point would be a disservice to users (as Alexandre and others have pointed out).

-Eric

[Eric Clayberg (Google)]

Jonathan,

1) Add a standard-compliant-warnings option to the editor for these use cases.

That is, in effect, exactly what we did. We implemented a "strict" mode for the Editor which is now the default. We did not remove the code that adds and removes warnings based on type inference, but it is turned off at the moment. Re-enabling the prior behavior would be easy. Resurfacing that behavior with a different presentation (for example, annotating warnings that are known false positives as well as reporting new warnings as hints) is a bit more work, but not hard at all.

 

2) Have these tools use the same analyzer as the editor.

That is always a possibility. IntelliJ's awesome Dart plugin, for example, does use the analyzer that we provide, and we are working with them to further improve the analyzer to suit their needs.

 

3) Optionally tell the tools to ignore warnings.

We would be happy with a a user opt-in mode that suppressed false warnings. The default would be strict spec compliance, but the user could choose to let the tools suppress any known false positives (as well as report new warnings when appropriate).

Can we at least agree that forcing the editor to disable type inferencing hurts programmer usability?

That would certainly be my personal opinion, but I also have great respect for Gilad's position here as well. If there are better solutions from Gilad's POV, we would be very inclined to implement those rather than what we have come up.

 

It hurts for me. I want my IDE to be as smart as possible.

Agreed! ;-)

 

Can't we compromise by adding an option to the editor to force spec-compliant warnings?

Well... that is what you have right now. You just don't have an option to turn it off ;-)

-Eric

 

[Lasse R.H. Nielsen]

If I have understood it correctly, the reasoning behind spec-mandated warnings is:

Developers don't like warnings. They generally prefer to write programs that don't cause warnings when compiled/run. It's mainly a safety and hygiene choice - irrelevant warnings can drown out important ones if you get used to seeing them.

If different tools have different warnings, it's impossible for a developer to know whether another will see warnings. If your IDE silences some warnings, you won't realize that you are releasing code that will cause these warnings in other tools.

So, every tool must show the same warnings, and therefore they must be specified centrally.

That also means that there is a limit on what can be specified, because the spec can't allow heuristics that may be interpreted differently, and it takes effort away from the language development to develop the static analysis in the spec as well.

Ofcourse that's only going to work if tool developers care about making their tools warning-spec compliant. The dartlang project managed tools like the Dart Editor, the dart analyzer and the dart2js compiler try to follow the spec. The VM doesn't generate static warnings at all.

Now we have users of the Editor asking for a non-spec compliant warning omissions. I would personally have no problem with having that as an opt-in choice. It's the user's development tool and development environment, and we should not take options away from it, especially if they are already there. 

If anything, I would like the error display in the Editor to have very easily used toggles to toggle between different error/warning filters. Then the analyzer can generate all the warnings, and the editor can show the ones the user cares about right now.

I expect third-party tools to do whatever they want in order to please their users, and giving a *known* useless warning is not helping anybody, so it'd be one of the first uses of a type analysis in any IDE.

We already see some tools display more warnings (call them "hints" instead if it would be a spec violation to call them "warnings"). You implicitly opt into those warnings by choosing the tool, and the tool may have a way to disable them. That means that the original goal is already defeated, so maybe we should reconsider it.

/L

--

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 email to misc+uns...@dartlang.org.

--
Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Florian Loitsch]

On Wed, Aug 28, 2013 at 4:10 PM, Lasse R.H. Nielsen <l...@google.com> wrote:

If I have understood it correctly, the reasoning behind spec-mandated warnings is:

Developers don't like warnings. They generally prefer to write programs that don't cause warnings when compiled/run. It's mainly a safety and hygiene choice - irrelevant warnings can drown out important ones if you get used to seeing them.

If different tools have different warnings, it's impossible for a developer to know whether another will see warnings. If your IDE silences some warnings, you won't realize that you are releasing code that will cause these warnings in other tools.

So, every tool must show the same warnings, and therefore they must be specified centrally.

That also means that there is a limit on what can be specified, because the spec can't allow heuristics that may be interpreted differently, and it takes effort away from the language development to develop the static analysis in the spec as well.

Ofcourse that's only going to work if tool developers care about making their tools warning-spec compliant. The dartlang project managed tools like the Dart Editor, the dart analyzer and the dart2js compiler try to follow the spec. The VM doesn't generate static warnings at all.

Now we have users of the Editor asking for a non-spec compliant warning omissions. I would personally have no problem with having that as an opt-in choice.

I disagree. The fact that this frequently comes up on the mailing list means that some developers would enable it, and there would be lots of libraries with warnings.

 

It's the user's development tool and development environment, and we should not take options away from it, especially if they are already there. 

If anything, I would like the error display in the Editor to have very easily used toggles to toggle between different error/warning filters. Then the analyzer can generate all the warnings, and the editor can show the ones the user cares about right now.

I expect third-party tools to do whatever they want in order to please their users, and giving a *known* useless warning is not helping anybody, so it'd be one of the first uses of a type analysis in any IDE.

I hate special casing, but if the "if (x is Y)" check was dealt with, almost all useless warnings were gone for me. Other warnings might be wrong, but I would understand that I shouldn't write code this way. So I vote in favor of adding this exception to the spec. Yes: we would get requests for better type-inference, but I would be much more comfortable rejecting those.

We already see some tools display more warnings (call them "hints" instead if it would be a spec violation to call them "warnings"). You implicitly opt into those warnings by choosing the tool, and the tool may have a way to disable them. That means that the original goal is already defeated, so maybe we should reconsider it.

Good point. 

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[Brian Wilkerson]

Eric,

 

 Otherwise they would already be excluded by the language spec.

That would indeed be the ideal solution.

 It is undesirable if each tool implements its own heuristics. We do not want a program developed without warnings on one tool to cause warnings on another.

Ideally, we should come up with a set of agreed upon heuristics (it could be a small set of very obvious cases to start) and then have all of the tools implement them. Codifying them in the spec would be even better.

I strongly disagree.

Codifying these rules in the specification would have the negative effect that in the future when we discovered another useful heuristic we wouldn't be able to implement it because it wasn't in the specification. Changing language specifications is a slow and arduous process (certainly once the specification has been declared to be stable). All this would accomplish is to further restrict the ability of tool providers to innovate for their users.

In my opinion, the specification should specify the minimal amount necessary to ensure that the syntax and semantics of Dart are consistent everywhere. I think that what's in contention here is whether the warnings that are produced by the tools are a necessary part of that consistency or whether it's acceptable for tools to tailor the list to show only what users of those tools are interested in seeing. Being a tool developer, I am, of course, in favor or giving tool developers as much freedom as possible :-).

I think that a much better solution is to agree that tools like Editor are free to deviate from the specification (in the matter of warnings) in order to provide users with a better experience. One of the primary arguments against this appears to be that it's confusing for users when the errors and warnings produced by different tools are not the same, and I agree, at least to some degree. But in my mind, tools that are confusing don't provide a better experience. It should then be the responsibility of the tool designer to figure out how to provide exactly the information the developers need and want in a way that isn't confusing. That's the real fun and challenge of developing good tooling. But it should not be the responsibility of the specification to dictate what tools can and can't do.

Brian

[Brian Wilkerson]

Florian,

Now we have users of the Editor asking for a non-spec compliant warning omissions. I would personally have no problem with having that as an opt-in choice.

 

I disagree. The fact that this frequently comes up on the mailing list means that some developers would enable it, and there would be lots of libraries with warnings.

Yes, some developers would enable such an option, and yes, there would be lots of libraries with warnings.

But if the tool doesn't provide utility by allowing them this option, then those developers will move to a different tool that does. There are already plenty of good alternatives. No matter what we do, there are developers who will use plain text editors that don't display any errors and warnings and who will ignore any warnings produced by other tools, and there will be lots of libraries with warnings. Tools can't prevent this. Nor should they be constrained by requiring that they try to prevent this.

What will (and should) control this is a community that refuses to use libraries that are not warning free (or at least free of valid warnings). The choice of which warnings (whether included in the specification or whether provided as hints by other tools) will ultimately be decided by the community.

Brian

[Alan Humphrey]

"or at least free of valid warnings" - this is the crux of the issue for me. How do I know which warnings are valid? If they're not valid why are you telling me about them? Most importantly, what do I need to do in my code to get rid of them?

Right now my code has tons of 'no such getter' warnings:

    var gm = js.context.google.maps;

Warning: There is no such getter 'google' in 'Proxy'

    form.queryAll("select, input").forEach((Element el) {

      if ( el.id == 'tree_id' ) {

        data['tree_id'] = el.value;

      }

There is no such getter 'value' in 'Element'

As far I can tell there's no way to get rid of these warnings. So what value do they provide?

--

[Jonathan Edwards]

I am very disappointed that Dart has taken this position so unlike its otherwise pragmatic philosophy. Clearly no amount of arguing is going to change anything at this point. Surely the editor/analyzer team has already fought and lost this battle - they can't have been happy being forced to turn off a lot of their type inferencing code just for some hypothetical future benefit of tool error consistency.

The best way to be heard on this issue is to vote with our feet. We have the options of forking the editor or jumping to IntelliJ, both of which will become easier after 1.0. For the moment I am holding at 26106 while I cool down.

Jonathan Edwards

 

[John Messerly]

On Wed, Aug 28, 2013 at 8:19 AM, Brian Wilkerson <brianwi...@google.com> wrote:

Eric,

 

 Otherwise they would already be excluded by the language spec.

That would indeed be the ideal solution.

 It is undesirable if each tool implements its own heuristics. We do not want a program developed without warnings on one tool to cause warnings on another.

Ideally, we should come up with a set of agreed upon heuristics (it could be a small set of very obvious cases to start) and then have all of the tools implement them. Codifying them in the spec would be even better.

I strongly disagree.

Codifying these rules in the specification would have the negative effect that in the future when we discovered another useful heuristic we wouldn't be able to implement it because it wasn't in the specification. Changing language specifications is a slow and arduous process (certainly once the specification has been declared to be stable). All this would accomplish is to further restrict the ability of tool providers to innovate for their users.

Why does the specification for these warnings need to be the Dart Language Specification? Why can it not be in a separate specification? The process for changing this specification would not need to be slow and arduous.

I don't understand how we got to a situation where specifying a handful of type inference heuristics that tools should use is too hard.

[John Messerly]

On Wed, Aug 28, 2013 at 3:33 AM, Gilad Bracha <gbr...@google.com> wrote:

What Dart has done is raise the bar for user expectations.  In a normal statically typed language, you are forced to restructure code to the compiler's satisfaction. With the introduction of optional typing, people are demanding more than they have ever asked from conventional type systems. Since they can run the code despite the warnings, they see no reason to change the code; they want the warnings to either be undeniably valid or go away. 

In my view, it is not Dart's optional type system that has raised the bar. It is that very few languages require you to write types for local variables nowadays, and they don't penalize you for not writing the type. It's almost unheard of for a new typed language to not support some basic type inference or propagation. Even older ones like C++ and C# have added this feature.

[Joao Pedrosa]

Hi,

I believe this change has been made in order to reduce the hypocritical accusations before and after Dart reaches 1.0.

Dart maybe was, maybe wasn't intended to be "statically typed." But if they didn't take a stance on this, we'd continue with this indefinition of maybe it is, maybe it isn't, maybe it works, maybe it doesn't. Maybe we should say this, maybe not. Maybe we'll be accused of being hypocritical. Maybe Dart is not like JavaScript after all, and we are pitching it like JavaScript.

As the core Dart designers will be doing a lot of talking about it, they need to sort it out before it gets uglier.

The deadline approaches.

My own files tend to have at most 1 warning at the top for an unused import that I use for debugging purposes. I'm unwilling to be commenting it out when I'm not using it. But I have seen other people complain about getting warnings that they can't suppress. Some of those come from coding with Dart in a more flexible, dynamic way with noMethodError and so on. But when even Google folks get warnings that they cannot suppress, you know it's not just because Dart is "dynamic."

The way I see it is that they waited till about the finish line for things to settle down, but now they cannot wait any longer. So perhaps making the default the other option can help to give people incentive to find new ways to work around the problem.

Cheers,

Joao

[Greg Lowe]

 

Why does the specification for these warnings need to be the Dart Language Specification? Why can it not be in a separate specification? The process for changing this specification would not need to be slow and arduous.

 

+1 for only specifying only errors in the language specification, and having warnings in a separate and more complicated spec (This would have to specify how type inference is used to generate warnings).

IMHO, for other tools implementing their own analyzer, a comprehensive test suite is probably going to end up being more useful than a detailed specification anyway.

[Mike]

Another possible solution in the editor would be to allow users to 'tick' warnings they don't mind - thereby relegating them off the code screen but still available if required to be reviewed in future. The editor could therefore dutifully warn, without keeping the warning forever in front of the programmer. Another programmer opening the same library would be told it contains 'accepted' warnings which would be available for review.

[Eric Clayberg (Google)]

Clearly no amount of arguing is going to change anything at this point.

Actually, I disagree. You wouldn't see so many of us Googlers posting passionately to this thread if nothing could change. ;-)

 

Surely the editor/analyzer team has already fought and lost this battle

I would say we lost a skirmish but the battle and the war are far from over! We are very passionate about doing the right thing for the user, sl I am sure we will come up with something.

 

they can't have been happy being forced to turn off a lot of their type inferencing code just for some hypothetical future benefit of tool error consistency.

True. We weren't very happy about that, but we did understand the motivation. Coming up with a solution that everyone agrees to will be better in the end (as opposed to the unilateral approach we were taking earlier).

 

The best way to be heard on this issue is to vote with our feet.

Or vote for Issue 12821 ;-)

-Eric

[Günter Zöchbauer]

As far as I understand the problem: 

Dart is a dynamic language and should behave like static for some scenarios (code completion, static analyzing/error checking, ...?)

I would prefer to be explicit about when Dart should be dynamic and when it should be static.

Maybe an additional keyword to distinguish when the type inference is demanded an when dynamic behavior is wanted would help (like var/dynamic in c#) .

I'm just a developer who wants to write high quality code efficiently, not an computer scientist or language designer - so please don't judge to harsh if I missed the point ;-).

In general I would prefer Dart to behave like a static language and notify me of any statement that is not valid from this point of view.

No doubt, there are situations where dynamic behavior is very useful and it is highly appreciated to have it available.

I don't care much though if dynamic or static is default, but I would like to be able to state explicitly when I want the one or the other.

Currently I have to add type annotations everywhere to benefit (analyzer, code completion) and still have situations left where I get unhelpful warnings (Alexandre' case 2).

This is the most annoying combination of all options (I understand that the entire discussion is about solving this issue).

[Lasse R.H. Nielsen]

On Wed, Aug 28, 2013 at 4:52 PM, Florian Loitsch <floi...@google.com> wrote:

On Wed, Aug 28, 2013 at 4:10 PM, Lasse R.H. Nielsen <l...@google.com> wrote:

If I have understood it correctly, the reasoning behind spec-mandated warnings is:

Developers don't like warnings. They generally prefer to write programs that don't cause warnings when compiled/run. It's mainly a safety and hygiene choice - irrelevant warnings can drown out important ones if you get used to seeing them.

If different tools have different warnings, it's impossible for a developer to know whether another will see warnings. If your IDE silences some warnings, you won't realize that you are releasing code that will cause these warnings in other tools.

So, every tool must show the same warnings, and therefore they must be specified centrally.

That also means that there is a limit on what can be specified, because the spec can't allow heuristics that may be interpreted differently, and it takes effort away from the language development to develop the static analysis in the spec as well.

Ofcourse that's only going to work if tool developers care about making their tools warning-spec compliant. The dartlang project managed tools like the Dart Editor, the dart analyzer and the dart2js compiler try to follow the spec. The VM doesn't generate static warnings at all.

Now we have users of the Editor asking for a non-spec compliant warning omissions. I would personally have no problem with having that as an opt-in choice.

I disagree. The fact that this frequently comes up on the mailing list means that some developers would enable it, and there would be lots of libraries with warnings.

And maybe the majority would enable it, and it would become the de-facto standard. Complain about a warning that is a) known to be incorrect and b) easily disabled, and you will just be laughed at.

Other tool vendors would include the disabling too, or have their tool ignored because it's not good enough.

It could go either way. 

As someone else pointed out, the only thing that can enforce "warning free" libraries is that the users of those libraries will complain or reject libraries with warnings. It's a community choice.

You can even have different sub-communities with different standards.

 

 

It's the user's development tool and development environment, and we should not take options away from it, especially if they are already there. 

If anything, I would like the error display in the Editor to have very easily used toggles to toggle between different error/warning filters. Then the analyzer can generate all the warnings, and the editor can show the ones the user cares about right now.

I expect third-party tools to do whatever they want in order to please their users, and giving a *known* useless warning is not helping anybody, so it'd be one of the first uses of a type analysis in any IDE.

I hate special casing, but if the "if (x is Y)" check was dealt with, almost all useless warnings were gone for me.

That is a "simple" case to mention, but somewhat hard to specify.

You need to specify which scope this test covers (both negative and positive).

You need to specify which operations may invalidate the test. Assignment to "x"? Assigning "x" to something else? Calling a function that may or may not change the value of "x"?

And it requires a data flow analysis to guide it, even if it's a simple one, which is not something we have in the spec now.

Just using "this particular variable has this known type in this scope" isn't the best one can do.

I would still like to allow a tool to have a better data-flow analysis and remove more invalid warnings.

 

Other warnings might be wrong, but I would understand that I shouldn't write code this way. So I vote in favor of adding this exception to the spec. Yes: we would get requests for better type-inference, but I would be much more comfortable rejecting those.

But I don't like preventing others from doing them anyway.

After all, I don't see people, except the ones writing the spec (the dartlang team), caring if their warnings are spec compliant anyway, as long as they are helping the programmer.

/L

[Vadim Tsushko]

Currently I have to add type annotations everywhere to benefit (analyzer, code completion) and still have situations left where I get unhelpful warnings (Alexandre' case 2).

This is the most annoying combination of all options (I understand that the entire discussion is about solving this issue).

I guess you may achieve warning free state if you would go futher in static direction :

   class MyBase {
    }
    
    class MySub extends MyBase {
      int x = 0;
    }
    
    void main() {
      MyBase o = new MySub();

      if (o is MySub && (o as MySub).x > 0) { // No warning after explicit cast
      }
    }

[Brian Wilkerson]

Günter,

Dart is a dynamic language and should behave like static for some scenarios (code completion, static analyzing/error checking, ...?)

Just to be clear, the only requirement is that tools must produce errors and warnings based on the static type information. There is no restriction on other functionality such as code completion, and Editor uses the propagated type information whenever possible. If you have entered

var s = 'string';

s.

code completion, for example, will show you choices appropriate to a String (which it knows because of type propagation). Editor also uses propagated type information to give better results for refactoring, code navigation, searching and other functionality.

Brian

[Jonathan Edwards]

On Thu, Aug 29, 2013 at 10:00 AM, Brian Wilkerson <brianwi...@google.com> wrote:

Günter,

Dart is a dynamic language and should behave like static for some scenarios (code completion, static analyzing/error checking, ...?)

Just to be clear, the only requirement is that tools must produce errors and warnings based on the static type information. There is no restriction on other functionality such as code completion, and Editor uses the propagated type information whenever possible. If you have entered

var s = 'string';

s.

code completion, for example, will show you choices appropriate to a String (which it knows because of type propagation).

And then as soon as you make one of those choices it suggested it will slap a warning message on it! Thank you very much Sir, may I have another?

Someone needs to do an intervention.

[Günter Zöchbauer]

I understand.

Thanks for clarification.

[Bob Nystrom]

On Thu, Aug 29, 2013 at 12:50 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Maybe an additional keyword to distinguish when the type inference is demanded an when dynamic behavior is wanted would help (like var/dynamic in c#) .

For what it's worth, Dart already has both of those. You can do:

var a = "value";

dynamic b = "value";

The first line declares a variable with no type annotation. In the absence of a type annotation, the spec states that its static type is "dynamic". The second line declares a variable using "dynamic" as the type annotation.

So, Dart has the syntax you ask for, but doesn't let you do anything useful with it.

- bob

[kc]

Keeping the DartVM checked mode and the tools in sync must be very tricky.

For the DartVM checked mode isn't very important imo - speed and stability in production mode is.

If checked mode was dropped the static checks could be removed from the language spec into a separate spec. And there could be much more useful type inference/data flow in this new spec - because it wouldn't be necessary to sync the logic with DartVM checked mode.

The core language spec could describe only what happens in production mode with the DartVM (and dart2js).

(My bugbear is that the type syntax is so similar to C/Java/C# that is gives users static expectations - whereas the DartVM in production mode is dynamic).

[Eric Clayberg (Google)]

At least in the case of "var" or "dynamic", it won't show a warning, so using "var" is one way to avoid the spurious warnings.

If you wrote it as "Object s =", then you would get a warning even though we know it's a String. How we choose to display that warning to the user is an interesting question and the subject of Issue 12821. I suppose there is some value in knowing that the type system detects a mismatch... especially if we could offer a clean refactoring that would eliminate the warning without reducing the readability.

In the case of assigning a String to a var and then calling a non-String method on the var, we do plan to add a hint that indicates that there is a problem.

[Bob Nystrom]

On Thu, Aug 29, 2013 at 1:43 PM, Eric Clayberg (Google) <clay...@google.com> wrote:

At least in the case of "var" or "dynamic", it won't show a warning, so using "var" is one way to avoid the spurious warnings.

My problem is not too many spurious warnings, it's too few legitimate ones because I use var everywhere. :(

If it wasn't for great test coverage, I wouldn't be able to refactor any of my Dart code anymore. Ever since the analyzer stopped showing warnings through inference, it's basically like flying blind.

- bob

[Eric Clayberg (Google)]

Showing warnings based on inference (now called Hints) will be coming back soon! Finding a good way to handle the false warnings is still an open issue.

Type inference is still used by all the other tools in the Editor like code completion, refactoring, etc.

[Bob Nystrom]

On Thu, Aug 29, 2013 at 2:27 PM, Eric Clayberg (Google) <clay...@google.com> wrote:

Showing warnings based on inference (now called Hints) will be coming back soon!

\o/

- bob

[Justin Fagnani]

This change had to go into polymer_expressions today to shut up the warnings:

while (expr is BinaryOperator && expr.operator != '|') {

  // ...

}

became:

while (expr is BinaryOperator) {

  BinaryOperator op = expr;

  if (op.operator != '|') {

    break;

  }

  // ...

}

This type of pattern does no one any good. I cried a little when I approved the CL.

[Eric Clayberg (Google)]

Gack! I think I just threw up a little in my mouth.

I'd love to see other examples of tortured refactorings caused by this change (as ammo for encouraging a better solution).

[jim.trainor.kanata]

The code examples I see here involve a type check followed by an implicit assumption that an access of that types interface will work based on that type check - but without an explicit cast.  The fix to quiet the warning is a type check followed by an explicit cast. That pattern: type check followed by explicit cast is exactly what would be needed in a strongly typed language.  So it does seem at odds with Dart's intentions to have warnings that force people into a strongly typed coding style.  However those warnings are justified in cases where there was no prior type check and personally I want them in that case.

Is there a simple pattern that will streamline the type-check-followed-by-explict-cast style?

Perhaps a variation of the "as" or "is" operators?  Maybe something where the cast returns null rather than throwing an exception?  e.g. a prettier version of:

BinaryOperator expr = (object is BinaryOperator ? object as BinaryOperator : null);
if (expr != null && expr.operator != '!') {
...
}

One way or another the type check has to happen in the cases I see here.  It is the transition from that type check into using the cast object that seems to be source of unhappiness.  So maybe find a way to roll up the type check and explicit cast into a single streamlined operation.


Ross Smith wrote:

> I'd love to see other examples of tortured refactorings caused by
this change (as ammo for encouraging a better solution).

Every class I have that overrides the == operator got a bit sadder.
Example:

bool operator ==(Object other) {
if(identical(this, other)) return true;
if(*other is! Rectangle*)returnfalse;
*Rectangle o = other;*
return left == o.left && top == o.top
&& width == o.width && height == o.height;

[Bob Nystrom]

On Thu, Aug 29, 2013 at 7:35 PM, Eric Clayberg (Google) <clay...@google.com> wrote:

I'd love to see other examples of tortured refactorings caused by this change (as ammo for encouraging a better solution).

Here's some code in pub that currently generates stupid pointless warnings on every marked line:

  VersionConstraint intersect(VersionConstraint other) {

    ...

    if (other is VersionRange) {

      // Intersect the two ranges.

      var intersectMin = min;

      var intersectIncludeMin = includeMin;

      var intersectMax = max;

      var intersectIncludeMax = includeMax;

      if (other.min == null) {

        // Do nothing.

      } else if (intersectMin == null || intersectMin < other.min) {

        intersectMin = other.min;

        intersectIncludeMin = other.includeMin;

      } else if (intersectMin == other.min && !other.includeMin) {

        // The edges are the same, but one is exclusive, make it exclusive.

        intersectIncludeMin = false;

      }

      if (other.max == null) {

        // Do nothing.

      } else if (intersectMax == null || intersectMax > other.max) {

        intersectMax = other.max;

        intersectIncludeMax = other.includeMax;

      } else if (intersectMax == other.max && !other.includeMax) {

        // The edges are the same, but one is exclusive, make it exclusive.

        intersectIncludeMax = false;

      }

      

      ...

    }

    ...

  }

and:

  void _logRequest(http.BaseRequest request) {

    ...

    if (request.method == 'POST') {

      ...

      if (request is http.MultipartRequest) {

        requestLog.writeln();

        requestLog.writeln("Body fields:");

        request.fields.forEach((name, value) =>

            requestLog.writeln(_logField(name, value)));

        // TODO(nweiz): make MultipartRequest.files readable, and log them?

      } else if (request is http.Request) {

        if (contentType.value == 'application/x-www-form-urlencoded') {

          requestLog.writeln();

          requestLog.writeln("Body fields:");

          request.bodyFields.forEach((name, value) =>

              requestLog.writeln(_logField(name, value)));

        } else if (contentType.value == 'text/plain' ||

            contentType.value == 'application/json') {

          requestLog.write(request.body);

        }

      }

    }

  }

In both cases, we just sit on those annoying distracting warnings because the current code is correct and optimally readable.

Here's an example from barback:

  void updateTransformers(Iterable<Iterable<Transformer>> transformers) {

    transformers = transformers.toList();

    for (var i = 0; i < transformers.length; i++) {

      if (_phases.length > i) {

        _phases[i].updateTransformers(transformers[i]);

        continue;

      }

      _addPhase(_phases.last.addPhase(transformers[i]));

    }

  }

In this case, transformer's type is changing, so I'd be more comfortable with defining a new variable here. But I would still prefer to not have to. The code is correct and the analyzer, if it didn't have features currently disabled, would be smart enough to know that.

Like Ross notes, we would also get lots of warnings from the multiple places we override == except that we don't type the parameter as Object like we should to get around this. :(

- bob

[Florian Loitsch]

On Fri, Aug 30, 2013 at 4:35 AM, Eric Clayberg (Google) <clay...@google.com> wrote:

Gack! I think I just threw up a little in my mouth.

wow. either you are exaggerating or your tolerance is extremely low...

Yes. this is a common pattern.

Justin could have used the as-operator, but apparently preferred the nested if.

[Eric Clayberg (Google)]

Just trying to inject some humour into an otherwise sad situation ;-)

I think the point is that being forced to use the as-operator or perform an inelegant refactoring to avoid a warning that the tools already know is bogus is painful... both to the users (including a great many folks on the Dart team itself) as well as to the team providing the tools. And I do have a low tolerance for self-inflicted pain...

[Bob Nystrom]

On Fri, Aug 30, 2013 at 10:40 AM, Eric Clayberg (Google) <clay...@google.com> wrote:

I think the point is that being forced to use the as-operator or perform an inelegant refactoring to avoid a warning that the tools already know is bogus is painful... both to the users (including a great many folks on the Dart team itself) as well as to the team providing the tools. And I do have a low tolerance for self-inflicted pain...

It's especially painful to have to make our code worse to please the type checker when meanwhile it fails to report valid type warnings, like in:

var a = "some string";

a.someMethodNotOnString();

Dart's motto has always been that you shouldn't have to make your code worse to shut up the type checker and it's sacrificed all manner of valid useful type errors on that altar (covariance, implicit downcasting!). To then turn around and say, "sorry, you've got to make your code uglier here" to avoid a warning that is trivially determined to be bogus is particularly frustrating.

- bob

[Justin Fagnani]

On Fri, Aug 30, 2013 at 10:13 AM, Florian Loitsch <floi...@google.com> wrote:

On Fri, Aug 30, 2013 at 4:35 AM, Eric Clayberg (Google) <clay...@google.com> wrote:

Gack! I think I just threw up a little in my mouth.

wow. either you are exaggerating or your tolerance is extremely low...

Yes. this is a common pattern.

Justin could have used the as-operator, but apparently preferred the nested if.

Cast has a non-zero cost, and it's a potential change in behavior in production mode. I'll argue that the nested if is the only behavior preserving refactoring of the two. Will dart2js be allowed to eliminate a redundant cast? Will it be able to detect that we really have a multi-clause while when it sees the nested if?

Why we would want to make our users even spend brain cycles on these things, I don't know.

[John Messerly]

+1. I think these are the options:

1. give up on static analysis completely, and rely on tests for refactoring, like you would in JavaScript.
   
2. put type annotations everywhere, and make code ugly like Java. Fix the style guide to require this style.
   
3. be optimistic and hope tools can be made better...
   

So far I've chosen #3, but it ends up being de facto equivalent to #1. Either way is a sad result. If I'm following the thread so far, we already know how to make the analyzer better, but are not doing it because ???

(side note: I don't understand the desire to support more than one analysis tool that implements warnings, either. Surely we can just implement it once and be done with it? What is the value in implementing it twice?)

[jim.trainor.kanata]

Dart has to be language where the tools permit reliable refactoring based on the type warnings. For me very about much of Dart's resonance is lost if that capability is weakened to severely.  The thought of a "javascript experience" where one must code without that ability and depend totally on test coverage is awful.  That's a barrier to Dart's adoption for the production of large scale applications and is exactly the opposite of Dart's reason to exist - at least as I've come to know it.

Front and center on dartlang.org is this message:  "A new language, with tools and libraries, for structured web app engineering".   So I see a message that has "structured wep app engineering".  Not a performance message, or a novel optional type message, or new packaging, or vm, or whatever.  It's about the ability of the language to support large scale application development.  If tools are not generating good, purposeful, errors, warnings, and hints, to guide the production of quality "structured web app" code the there is a real problem. This issue seems rather fundamental in this regard.

John Messerly wrote:

On Thu, Aug 29, 2013 at 1:58 PM, Bob Nystrom <rnys...@google.com
<mailto:rnys...@google.com>> wrote:


    On Thu, Aug 29, 2013 at 1:43 PM, Eric Clayberg (Google)

    <clay...@google.com <mailto:clay...@google.com>> wrote:

        At least in the case of "var" or "dynamic", it won't show a
        warning, so using "var" is one way to avoid the spurious warnings.


    My problem is not too many spurious warnings, it's too few
    legitimate ones because I use var everywhere. :(

    If it wasn't for great test coverage, I wouldn't be able to
    refactor any of my Dart code anymore. Ever since the analyzer
    stopped showing warnings through inference, it's basically like
    flying blind.


+1. I think these are the options:

1. give up on static analysis completely, and rely on tests for

    refactoring, like you would in JavaScript.

2. put type annotations everywhere, and make code ugly like Java. Fix

    the style guide to require this style.

3. be optimistic and hope tools can be made better...

So far I've chosen #3, but it ends up being /de facto/ equivalent to

#1. Either way is a sad result. If I'm following the thread so far, we
already know how to make the analyzer better, but are not doing it
because ???

(side note: I don't understand the desire to support more than one
analysis tool that implements warnings, either. Surely we can just
implement it once and be done with it? What is the value in
implementing it twice?)

[kc]

On Friday, August 30, 2013 7:37:19 PM UTC+1, John Messerly wrote:

+1. I think these are the options:

1. give up on static analysis completely, and rely on tests for refactoring, like you would in JavaScript.
   
2. put type annotations everywhere, and make code ugly like Java. Fix the style guide to require this style.
   
3. be optimistic and hope tools can be made better...
   

So far I've chosen #3, but it ends up being de facto equivalent to #1. Either way is a sad result. If I'm following the thread so far, we already know how to make the analyzer better, but are not doing it because ???

Difficulties with type inference in checked mode in the DartVM?

 

[Alex Tatumizer]

Obviously, if editor can infer type, it should do it - hopefully, the feature will be reinstated
BUT I think there will always be situations where analyzer will print false warnings because it REALLY cannot infer the type ,causing programmer
to lose temper and post complaints and grievances.
In this cases, is it possible to come up with mechanism of disabling warnings individually?
E.g. you go to "Problems" tab and click "disable" for individual message. Warning will still show up, but in greyed out mode.
How to trace these messages when program gets modified is a different issue, but probably diff can help.

[John Messerly]

On Fri, Aug 30, 2013 at 12:44 PM, kc <kevin...@gmail.com> wrote:

Difficulties with type inference in checked mode in the DartVM?

the VM doesn't do any static analysis, so I don't think it is relevant.

[Florian Loitsch]

On Fri, Aug 30, 2013 at 8:36 PM, Justin Fagnani <justin...@google.com> wrote:

On Fri, Aug 30, 2013 at 10:13 AM, Florian Loitsch <floi...@google.com> wrote:

On Fri, Aug 30, 2013 at 4:35 AM, Eric Clayberg (Google) <clay...@google.com> wrote:

Gack! I think I just threw up a little in my mouth.

wow. either you are exaggerating or your tolerance is extremely low...

Yes. this is a common pattern.

Justin could have used the as-operator, but apparently preferred the nested if.

Cast has a non-zero cost, and it's a potential change in behavior in production mode.

I can't see any case where the VM or dart2js don't remove the second is-check (that is hidden in the 'as'). I couldn't find a case where the behavior changes in production mode either. You just made an is-check. The as-operator is the identity operation in this case.

[Brian Wilkerson]

John,

If I'm following the thread so far, we already know how to make the analyzer better, but are not doing it because ???

Actually, we are actively working to make the analyzer better. We're actually doing this on three fronts simultaneously.

First, we're trying to convince the language team to loosen some of the restrictions on tools so that we can have a more optimal solution. This thread and a couple of issues in the issue tracker are at the forefront of that effort.

Second, we're working on putting support in place to report hints when propagated type information tells us that there's a problem that static type information didn't identify. These hints will be clearly different from specified warnings, but will hopefully be easy to use.

Third, as an alternative in case the first effort doesn't get us anywhere, we're looking into ways of identifying specified warnings generated based on static type information that wouldn't have been generated if we had used propagated type information. How that will manifest itself in both Editor and the command line analyzer is being discussed, but we're hopeful that we can do something that is good for the user while still remaining spec. compliant.

(side note: I don't understand the desire to support more than one analysis tool that implements warnings, either. Surely we can just implement it once and be done with it? What is the value in implementing it twice?)

One of the primary reasons at the moment is the fact that both dart2js and the Editor need the results of an analysis, but they are written using different languages (Dart and Java respectively) and there is no Java to Dart interop story.

Brian

[John Messerly]

On Fri, Aug 30, 2013 at 1:54 PM, Brian Wilkerson <brianwi...@google.com> wrote:

John,

If I'm following the thread so far, we already know how to make the analyzer better, but are not doing it because ???

Actually, we are actively working to make the analyzer better. We're actually doing this on three fronts simultaneously.

First, we're trying to convince the language team to loosen some of the restrictions on tools so that we can have a more optimal solution. This thread and a couple of issues in the issue tracker are at the forefront of that effort.

Second, we're working on putting support in place to report hints when propagated type information tells us that there's a problem that static type information didn't identify. These hints will be clearly different from specified warnings, but will hopefully be easy to use.

Third, as an alternative in case the first effort doesn't get us anywhere, we're looking into ways of identifying specified warnings generated based on static type information that wouldn't have been generated if we had used propagated type information. How that will manifest itself in both Editor and the command line analyzer is being discussed, but we're hopeful that we can do something that is good for the user while still remaining spec. compliant.

Thanks Brian. This makes me feel a lot less worried. :)

One thing I am wondering: will hints will be available outside of the editor, for example by running "dartanalyzer"? Essentially if I have a codebase and I want it to be statically checked, can it be done aside from manually opening code in the Editor?

 

(side note: I don't understand the desire to support more than one analysis tool that implements warnings, either. Surely we can just implement it once and be done with it? What is the value in implementing it twice?)

One of the primary reasons at the moment is the fact that both dart2js and the Editor need the results of an analysis, but they are written using different languages (Dart and Java respectively) and there is no Java to Dart interop story.

I think that's why I'm confused -- why does dart2js need to emit warnings, when the VM does not? Couldn't we use dartanalyzer in both cases?

[Brian Wilkerson]

John,

One thing I am wondering: will hints will be available outside of the editor, for example by running "dartanalyzer"? Essentially if I have a codebase and I want it to be statically checked, can it be done aside from manually opening code in the Editor?

Yes. I don't think we've added a flag for it yet, but we intend to add a flag to dartanalyzer to produce (or possibly suppress) hints.

I think that's why I'm confused -- why does dart2js need to emit warnings, when the VM does not? Couldn't we use dartanalyzer in both cases?

The specification reads:

Static warnings must be provided by Dart compilers used for program development such as those incorporated in IDEs or otherwise intended to be used by developers for developing code. Compilers that are part of runtime execution environments such as virtual machines should not issue static warnings.

Both dart2js and dartanalyzer fall into the first category, and both are required to be spec. compliant. Hence, both need to produce all of the warnings from the specification.

Brian

[Bob Nystrom]

On Fri, Aug 30, 2013 at 12:00 PM, jim.trainor.kanata <jim.train...@gmail.com> wrote:

Dart has to be language where the tools permit reliable refactoring based on the type warnings. For me very about much of Dart's resonance is lost if that capability is weakened to severely.  The thought of a "javascript experience" where one must code without that ability and depend totally on test coverage is awful.  That's a barrier to Dart's adoption for the production of large scale applications and is exactly the opposite of Dart's reason to exist - at least as I've come to know it.

Front and center on dartlang.org is this message:  "A new language, with tools and libraries, for structured web app engineering".   So I see a message that has "structured wep app engineering".  Not a performance message, or a novel optional type message, or new packaging, or vm, or whatever.  It's about the ability of the language to support large scale application development.  If tools are not generating good, purposeful, errors, warnings, and hints, to guide the production of quality "structured web app" code the there is a real problem. This issue seems rather fundamental in this regard.

Well said.

- bob

[John Messerly]

On Fri, Aug 30, 2013 at 2:26 PM, Brian Wilkerson <brianwi...@google.com> wrote:

I think that's why I'm confused -- why does dart2js need to emit warnings, when the VM does not? Couldn't we use dartanalyzer in both cases?

The specification reads:

Static warnings must be provided by Dart compilers used for program development such as those incorporated in IDEs or otherwise intended to be used by developers for developing code. Compilers that are part of runtime execution environments such as virtual machines should not issue static warnings.

Both dart2js and dartanalyzer fall into the first category, and both are required to be spec. compliant. Hence, both need to produce all of the warnings from the specification.

Yeah, but it still doesn't make sense why the spec says that :). (Or why dart2js can't implement it by shelling out to dartanalyzer.)

[Brian Wilkerson]

John,

Yeah, but it still doesn't make sense why the spec says that :).

For that I have no answer. I personally believe that the specification should only specify the syntax and semantics of the language and not place restrictions on tools that are not related to those topics (but then, I'm a tool writer, not a specification writer :-).

(Or why dart2js can't implement it by shelling out to dartanalyzer.)

Because that would be far too slow.

Brian

[Bernhard Pichler]

My English capabilities are not that good, but this is exactly what i would have said! 

It's very sad to even see this discussion. The tools should be as good as possible without any constraints!

[John Messerly]

Thanks for your patience Brian. If you will humor me once more, here's what I still don't understand:

A typical development cycle is something like:

    edit -> refresh -> (repeat) -> analyze -> edit -> (repeat) -> (repeat all) ... -> deploy -> ...

I would use a cycle like this whether using the Dart Editor or some other editor.

In other words, I would like the analyzer to be much sooner in the cycle than deployment. Ideally integrated with the editor itself (as Dart Editor does). By the time I run dart2js, I have already run the analyzer many times. I don't need dart2js to run the same analysis again.

[Brian Wilkerson]

John,

A typical development cycle is something like:

    edit -> refresh -> (repeat) -> analyze -> edit -> (repeat) -> (repeat all) ... -> deploy -> ...

I would use a cycle like this whether using the Dart Editor or some other editor.

In other words, I would like the analyzer to be much sooner in the cycle than deployment. Ideally integrated with the editor itself (as Dart Editor does). By the time I run dart2js, I have already run the analyzer many times. I don't need dart2js to run the same analysis again.

Agreed. That's the process I'd use too.

But not all Dart developers will always do that. I'm guessing that the requirement for dart2js to also perform this analysis is so that those errors and warnings will be reported somewhere in the process. But I'm just guessing.

Brian