Namespace nested within incomplete `class` gets confused with identically-named top-level namespace

[distractedlambda]

#lang rhombus

class Foo():
  export math
  namespace math:
    def my_pi = Foo.math.pi /* succeeds, but should not */

def my_other_pi = Foo.math.pi /* correctly fails */

[mflatt]

I'm not sure this is fixable. It has to do with the imperative nature of shadowing an import with a definition at the module level combined with class wanting to make the defined class name available earlier.

Specifically, at the point where Foo.math.pi is expanded for the definition of my_pi, the context is effectively:

#lang rhombus

class Foo():
  export math
  <expanding `Foo.math.pi` here>

at which point Foo.math resolves to math as provided by rhombus. It's only after that expansion that we get to

#lang rhombus

class Foo():
  export math
  namespace math:
    def my_pi = rhombus.math.pi

to bind Foo.math and shadow math as exported by Foo, but Foo.math.pi on the right-hand size of my_pi has already been resolved by that point.

"But", you may ask, "why is Foo already bound but Foo.math is not?" After all, in

namespace ns:
  export math
  def math = ns.math.pi

then there's an error because ns is not yet bound. The difference is that class goes out of its way to bind the class name as a namespace before handling expressions at definition at the end of the class form. It can only do that after all class clauses have been found. If you add a method after namespace math in Foo, then the definition of math has to happen before the definition of Foo.

#lang rhombus

class Foo():
  export math
  namespace math:
    def my_pi = Foo.math.pi /* fails:`Foo` is not defined */
  method m(): 0

A different choice would be for class not to try to define the class name early in this special way — and that's how it was for a long time. But this special handling avoids some confusion and a lot of bureaucracy to to add functions (especially things like from_handle) to a class as a namespace.

I'm not really happy with either choice, but my experience so far is that the current one is the lesser evil — and, of course, I haven't found a better third option, but I'm open to suggestions!

For more on the current choice in class: https://docs.racket-lang.org/rhombus-guide/class-namespace.html. I don't think I have anything so specific to point to, currently, about shadowing and the underlying side effect on bindings.

[distractedlambda]

If I'm understanding the explanation correctly, then something that seems particularly wrong to me is that an exported name can mean something different at different points in expansion. What if namespace-nested export didn't "take effect" until either (1) expanding a matching definition or (2) completing expansion of all definitions in the namespace (and then being able to properly determine that the export refers to something from outer scope)? Would that "fix" the problem in this example?

Also, thinking about it, why isn't the early binding of the namespace name, the behavior for namespace as well? If it were, would that also make this example work correctly?

Lastly, I'm not sure I actually like that namespace-nested export can re-export something from outer scope; or rather, I'd be more comfortable with it being somehow opt-in, such that the default behavior would be to only resolve names-to-export within the namespace itself.