Lexical scope comes before inherited scope

[peter-ahe-google]

$ cat fisk.dart
int x = 89;

class Foo {
  int x = 42;
}

class Bar extends Foo {
  m() => x;
}

main() {
  print(new Bar().m());
}

$ frogsh fisk.dart
42
$ dartc_test fisk.dart
89
$ cat fisk.dart

class x {
}

class Foo {
  int x = 42;
}

class Bar extends Foo {
  m() => x;
}

main() {
  print(new Bar().m());
}
$ frogsh fisk.dart
42
$ dartc_test fisk.dart
fisk.dart:9: x is a class and cannot be used as an expression
     8: class Bar extends Foo {
     9: m() => x;
Compilation failed with 1 problem.

FWIW, there are a bunch of tests in dart/compiler/javatests/com/google/dart/compiler/{resolver,type}. Karl is already working on porting the tests from the type directory.

[jmesserly]

Set owner to @jmesserly.
Added Started label.

[jmesserly]

The VM prints 42 as well.

Gilad, can you give me a sanity check here. Is this is a bug in both implementations? Or misinterpretation of the spec?

Personally--I would really like to keep the current behavior of the VM and Frog. I find it much less surprising to bind to inherited names before top-level names, and I don't like how it makes things from the superclass different from names in my own class. I fear if I make this change to Frog, we'll end up with style rules like "always use 'this.' before members" and/or "never use top level names". That wouldn't be a good result.

---

Set owner to @gbracha.
Removed this from the FrogEditor milestone.
Removed Area-Frog label.
Added Area-Language, Triaged labels.
Changed the title to: "Lexical scope comes before inherited scope?".

[jmesserly]

The way I was thinking about this (correctly or not):
  class Bar extends Foo {
    m() => x;
  }

because Bar "extends Foo", Bar gets all the members of Foo, therefore "x" is in its lexical scope. By contrast, members of subtypes of Bar (if any) don't resolve in Bar. That's how I recall the discussion going last time this came up.

[peter-ahe-google]

In the future, please follow this process for requesting specification clarification:

1. File a new issue.
2. Mark the current bug as blocked on this issue.

Otherwise, the new owner of the bug is likely to forget that he should not close the bug but reassign back. If there are further follow-up questions a bug can fluctuate between various areas and tend to be forgotten when you perform bug scrubs. You may also loose labels in the process.

---

Removed the owner.
Added this to the FrogEditor milestone.
Removed Area-Language label.
Added Area-Frog label.

[gbracha]

The answer is 89. Lexical scope has priority over inherited scoped. The reason for this is mainly to bullet proof us against future features that might come up, like class nesting, first class libraries and how they interact.

[jmesserly]

Bullet proofing future features is definitely good :)

Just to double check my understanding--does "lexical scope" include top level names from other source files and imported libraries too, or just the current file?

I'm mainly worried from two angles: how do I bullet proof code within my own Dart classes from accidentally referring to something it didn't intend? And as a library designer, how do I add a new top level name without breaking someone else's class members? It seems like every top level name has the potential to conflict with any member variable/function. We're okay on type names because our UpperCamelCase names are unlike to conflict with lowerCamelCase member names, but for things like "document" "window" etc, what should we do?

[peter-ahe-google]

"Lexical" scope does include top-level names from everything #source'd and #import'ed into the current library.

We recommend importing stuff you're not in control of with prefixes. This way you reduce the "lexical" scope.

We should warn when there are conflicts (Gilad is looking at a minor tweak to the specification of this). The issue is what happens when you ignore the warnings. We need to have a tie-breaker rule and our experience is that the letting the superclass take precedence or lexical scope is not helpful.

[jmesserly]

Importing everything by prefix is not a solution. Sure you can work around the surprising conflict resolution rules like that--but I'd rather get the conflict resolution rules right, and not have to work around it. I can't imagine trying to sell Java developers on qualifying type names, much less JS devs or anyone from a more dynamic language background.

RE scoping: isn't the whole point of declaring a superclass of a class "bring these names and functions the scope of my object"?

[munificent]

We recommend importing stuff you're not in control of with prefixes. This way you reduce the "lexical" scope.

I've heard you say that before, but it's in contradiction with our practices. If you look through all of our existing code it almost never uses prefixes.

We should warn when there are conflicts (Gilad is looking at a minor tweak to the specification of this).

I like this. I don't see much reason to use prefixes when there aren't name collisions anyway.

[jmesserly]

oops--I forgot the word "into" above, that should've read:
"bring these names and functions into the scope of my object"

[jmesserly]

Here's another thought: if we want to preserve maximum flexibility for future features, why not make conflicts between inherited and lexical scope be an error? Means we'd never have to guess which name the user wanted and surprising them if they are used to this working in other languages.

Maybe we should also change the coding style guide to either say "avoid top-level functions in libraries", and/or "derived classes should always use 'super.' to access anything from the parent class".

BTW, I tried to construct a similar example in C#, but the rules of the language make it pretty hard--there's no top level functions and I couldn't figure out how to make it ambiguous about whether you wanted a class name or a member name. But if I create "class Foo {}" it doesn't conflict with methods called "int Foo()" in other classes (upper case member names are the normal C# convention).

The example translates quite easily to Ruby, where inherited scope wins:

def x(); 89; end
class Foo
  def x(); 42; end
end
class Bar < Foo
  def m(); x; end
end
class Baz
  def m(); x; end
end
puts(Bar.new.m) # prints 42
puts(Baz.new.m) # prints 89

(Of course, Python/JavaScript avoid this problem by requiring explicit "self."/"this.")

---

Changed the title to: "Lexical scope comes before inherited scope".

[dgrove]

Can you open a language bug for the feature discussion?

[kasperl]

Removed this from the FrogEditor milestone.

[DartBot]

This comment was originally written by jimhug@google.com

---

I'm still very interested in the language discussion continuing on this one. However, I'm going to try to fix this as part of a related cleanup to Value today - mainly to see how I feel about the semantics after I've implemented them <smile>. Any pointers to automated versions of these tests that are part of one of the standard test suites would be very much appreciated if available.

---

Set owner to jimhug@google.com.
Added Started label.

[rakudrama]

I don't understand the motivation for the lookup rule.

As per Peter's request I have opened Issue #1180 as a language issue, so this issue can stay focused on Frog's conformance.

---

Marked this as being blocked by #1180.

[sethladd]

I started writing an article on lexical scopes, but found that the VM still prints 42. Is there an issues specific to the VM for this? This issue is only for Frog.

[peter-ahe-google]

I've created issue #1598 to track the VM bug.

---

Removed the owner.
Added Triaged label.

[anders-sandholm]

Removed Area-Frog label.
Added Area-Dart2JS, FromAreaFrog labels.
Marked this as being blocked by #1180.
Unmarked this as being blocked by #-1180.

[kasperl]

Added WontFix label.