Type names and function names should be in disjoint namespaces.

[jdn]

This ticket is actually against a number of issues that the following example shows:

  trait Element
  end

  Element(a:ZZ32):Element = Element(a, 0, 0)
  Element(a:ZZ32, b:ZZ32):Element = Element(a, b, 0)
  Element(a:ZZ32, b:ZZ32, c:ZZ32):Element = do
     (MyImplementationDetail(a,b,c) asif Element)
  end

  object MyImplementationDetail(a, b, c) extends { Element } end

The first and probably easily understandable issue is that the code gives this error: Attempt to extend object type Element, saw Local@0/0 Which is not true, because Element is a trait and not an object. Also, Local@0/0 looks like an empty span of some sort.

The second and more serious issue is a proposal for language change. Type names and function names should be in disjoint namespaces.

Consider the situation where we want to do some computation on the creation of the object called MyImplementationDetail , then we define the toplevel function Element(a:ZZ32, b:ZZ32, c:ZZ32) and MyImplementationDetail now becomes an implementation detail. The user of this component should never be aware of the existance of MyImplementationDetail . However the return type of the overloaded Element functions becomes MyImplementationDetail , which exposes information about the implementation. To change that I would like to define the trait Element which is used as return type in the example above. However that is not possible: Attempt to extend object type Element, saw Local@0/0 .

[victorl]

I agree with your proposal. Actually, type names and functions names are in separate namespaces, but we originally had a relatively strong policy against names having multiple meanings, even for separate namespaces (e.g., types vs values vs labels), on the principle that the programmer should just choose different names to avoid later confusion. Top-level objects were the main exception, which defined a value and a type with the same name. But we run into problems like the one you describe here, where it would be natural to have the same name for a type and a factory that creates instances of that type.

A separate but related question is whether labels (for labeled blocks and exit expressions) should be allowed to be the same as declared type or value names. Currently, the answer is no, and I'm less sure we should relax this in this case, because labels are entirely local, so programmers can just choose different names without affecting any interfaces. On the other hand, labels appear in disjoint contexts from type or value names, so there is never any actual ambiguity.

[dr2chase]

FYI, the error reported is from an early pass in the interpreter, where it is trying to classify names. The earlier parts of static analysis may be quite ok with this change, already.