Unqualified name resolution

[vpetrovykh]

The status quo is that any short name is ultimately resolved to some fully-qualified name in the following manner:

• Look for a match to the short name in the current module (typically default, but it can be changed).
• Look for a match to the short name in the std module.

(taken from our docs as of 1.0 Alpha 2)

Why is this an issue at all?

module default {
    type Position {
        required property x -> float64;
        required property y -> float64;
    }

    function to_str(val: Position) -> str {
        using (
            SELECT '(' ++ <str>val.x ++ ', ' ++ <str>val.y ++ ')'
        );
    }
}

Consider how the following two queries should be resolved:
SELECT to_str(Position);
SELECT to_str(datetime_current(), 'Mon DDth, YYYY');

This is fairly unambiguous w.r.t. types and other entities with globally unique names as for any given unqualified name there's only one possible match in each of the modules, so basically we check the current module and then fallback to std.

Things get a bit less straightforward with functions which are identified by their name + signature. So when looking for a function by name only we necessarily must allow multiple matches as a possible outcome. There are at least two way of interpreting the rule above:

1. Look for all polymorphic versions of the function with the specified name in the current module. If such functions are found, that's the set of polymorphic functions that we resolved. Otherwise, if and only if no function by that name exists in the current module, fallback to std and check there. Given that set of polymorphic function versions pick the one matching the call signature.
2. Find all the functions with distinct signatures that match the specified name in the current module and in std (as long as the std function is not masked by an identical signature function from the current module). Then from this set of polymorphic functions pick the one matching the call signature.

Basically the approach 1) treats all versions of the function of the same name but different signature as a single entity, a single polymorphic function (which is consistent with the polymorphic function abstraction). This reduces functions to the same status as other objects regarding having at most one with a given name in any module and the resolving logic is consequently identical.

Approach 2) treats every function with different signature as it's own separate object (which is consistent with the schema where polymorphic variants are defined through separate definitions and exist as separate objects). Unique names are not necessary, but instead it's the name + signature which have to be unique. So under this definition it makes sense that as long as functions in std have different signatures from the ones found in the current module, they should not be masked and must be resolved as valid polymorphic options for the given name.

Another perspective to consider is what "std is always available" really means if we were to try to rephrase it:

1. Imagine all modules as separate pages. When resolving things, pick the "current" page, check it, and only if you don't find things, pick up std page and check there. Kinda like looking through a paper booklet.
2. Imagine that you have a blank slate. First copy everything from std onto it. Then copy and possibly overwrite (for masking objects) everything from the current module onto it. This is your working namespace for unqualified names. Kinda like a couple of transparencies superimposed over each other.

[vpetrovykh]

Personally, I have been thinking of implicit inclusion of std as similar to how imports work in other languages. I have been given the explanation of "this is like copy-pasting the contents of one file into another" for how includes/imports/etc. (#include "foo.h", import * from foo, using namespace foo) work in many programming languages. At least how they work in terms of an equivalent mental model, if not actually literal manipulation. This is evident if you have name clashes and things get masked in order of appearance of imports/includes/etc. or can be masked by a definition in the current module. So I favor interpretation 2).

As a useful feature, this interpretation allows extending the built-in utility functions to custom user-defined types in a fairly natural way (like the to_str example) without breaking existing functionality (because none of the existing code would use the new type and wouldn't require that polymorphic function variant).

The way I see it, the whole reason for deliberately giving your function a name matching a std function is when the intent is to indicate that it basically does the same thing for your type. So the intent is to extend the existing patterns, not to mask them. On the other hand, intentional masking of existing std function with an incompatible one is a less clear use case to me.

[1st1]

Victor, thanks for neatly and clearly summarizing the proposal in the first message.

First, I want to ask to refrain from using other languages in this discussion as justifications for one or another approach. I do that myself sometimes and now I see how it distracts us from thinking in the "EdgeQL box". C++/Python/PostgreSQL all have their own type systems, philosophies, restrictions, and goals. We can draw inspiration from other languages, but we shouldn't aim to copy their functionality. When we are discussing a new feature we should try to see how exactly it would benefit EdgeDB users within our type system constraints and EdgeQL capabilities. Let's try to dissect this feature proposal that way.

Currently we resolve functions using "interpretation 1" as you defined it. Let's do an exercise and see what happens if we adopt the "interpretation 2". On the surface it looks like it would enable better polymorphism: essentially users would be able to overload generic std:: functions such as to_str() which is handy.

Given the schema you defined previously:

module default {
    type Position {
        required property x -> float64;
        required property y -> float64;
    }

    function to_str(val: Position) -> str {
        using (
            SELECT '(' ++ <str>val.x ++ ', ' ++ <str>val.y ++ ')'
        );
    }
}

the SELECT to_str(Position) query is indeed unambiguous. So far so good.

Let's now evolve the schema a bit by adding another module and subtyping the Position type. After all, EdgeDB implements multiple inheritance and we're thinking of many ways of how we can have reusable libraries of types and functions:

module default {
    type Position { ... }
    function to_str(val: Position) -> str { ... }
}

module tagged {
    type TaggedPosition extending Position {
        required property tag -> str;
    }

    function to_str(val: TaggedPosition) -> str {
        using (
            SELECT val.tag ++ '(' ++ <str>val.x ++ ', ' ++ <str>val.y ++ ')'
        );
    }
}

Now the SELECT to_str(Position) query is not so easy to interpret. What if there are objects of TaggedPosition in the DB? What to_str implementation would the system call?

Using the "interpretation 2" that you're suggesting, the default::to_str() function would always be called, both for Position and TaggedPosition objects.

Is that what the user actually wanted to do? If I were that user, it would certainly be not. I'd expect the default::to_str to be called on Position objects and tagged::to_str to be called on TaggedPosition objects. And when it would not happen, I'd blame EdgeQL for being poorly designed, because it gave me an illusion of proper polymorphic overloading of std:: functions, whereas in reality it's quite limited.

This is the deal breaker I see with the "interpretation 2". It would basically "force" users to have just one module (maybe most users would have one module anyways, but that's not the point). Essentially having only the "default" module is the only way how you'd enable overloading of std:: consistently and predictably.

For what it's worth I don't think this problem is solvable by allowing you to specify multiple "current modules", e.g. with WITH MODULE default, MODULE tagged SELECT to_str(Position). Again, it appears as if this would fix it, but not really. As soon as you yet another module with another subtype of Position and yet another to_str overload, you'd be forced to go and update all your queries to add , MODULE newmodule to them.

There are other ways of solving the problem, like having no module for functions at all (making the global objects). But I'm afraid that ship has sailed. I really want us to stop changing the semantics of EdgeQL and focus on shipping a stable version of the product.

That said, in the future it's likely we will want to solve this problem. Once we have a GIS extension users would likely want std::to_str to support the GIS types (at least that's my current expectation). For that to happen I think we'll need to figure out how to allow to overload std::to_str directly in extensions, and maybe in regular modules for regular types. That would give you true flexibility in overloading std:: stuff. And it would be a backwards compatible feature.

---

The way I see it, the whole reason for deliberately giving your function a name matching a std function is when the intent is to indicate that it basically does the same thing for your type. So the intent is to extend the existing patterns, not to mask them.

That's questionable. Maybe you did it by accident? Or say you've deliberately defined your own contains(MyType, OtherType) that has nothing to do with std::contains(str, str) conceptually.

---

To sum up, given the above complication of "interpretation 2" I'm -1 on the proposal. There's nothing wrong with the current approach. It works, it's well defined, it's consistent, and it does not create false illusions of things we don't properly support.

[1st1]

@elprans We need to decide on this in the next 2 weeks so that we have enough time before a4.

[1st1]

We've decided to keep the status quo: we don't implement cross-module function matching by short name.

We do, however, need to eventually implement a concept similar to Rust's traits: a way to define a to_str trait for your types. Potentially traits would be a special kind of functions implementing single dispatch by their first argument. Because of that we do want to make sure that functions don't name-clash with other objects: it's invalid to have a function sharing a short name with a type, just as it would be invalid to have a regular function sharing a short name with a trait.

I'm going to close this issue and open two new ones for adding traits and prohiniting name clashing.