Should the type checker forbid function overloading across different scopes?

[PaulKlint]

At the moment the compiler assumes that all overloaded functions are declared in the same scope, be it the module scope or a nested function scope. For instance, the following two examples are fine:

int h() = n;
int h(int  x) = x;

and

int g(int n){
    int h() = n;
    int h(int  x) = x;
    return h(n);
}

However, triggered by code examples in CheckTypes.rsc (one of several exhibits: addAlias) the following structure is also used where h is overloaded but the versions are defined in different scopes:

int h(int n){
    int h(int  x) = x;
    return h(n);
}

I can probably modify the compiler to support this but this may have extra costs in compiler complexity and execution overhead.

_Question_: what happens if we forbid this kind of overloading across different scopes?

[mahills]

Probably very little would happen -- this happens right now in the checker more by accident (I wasn't very creative in coming up with new names), and would be easy to detect and flag. The other alternative would be to say that it creates a new function, not an overload, which is probably the intended behavior in most of the cases where this would arise, but that has the problem of being potentially confusing.

[jurgenvinju]

Just a note, the example:

int h(int n){
    int h(int  x) = x;
    return h(n);
}

is type incorrect if we talk about the overloading variant, since both alternatives are for the same pattern.

[jurgenvinju]

I think the function scope is a real scope with shadowing, so function names should be shadowed as well. One nice point of a local function is that you can pick a nice short name and you don't have to think hard about that, with the current semantics the programmer actually may accidentally overload another function without realizing.

[mahills]

Note: the actual case in the checker has been removed, but we still need to handle the situation, one way or another, more generally.

[PaulKlint]

Yes I have noticed. I can now compile CheckTypes and after fixing some serious bugs in the compiler (I will summarize when I am done with CheckTypes) now only a few dozen of the type checker tests are still failing. I maybe done with the type checker in a week or so

[mahills]

Hi @PaulKlint I knew that you knew, it's just ridiculously early at the airport so I'm updating status messages on GitHub :)

[PaulKlint]

Take care! Maybe a brief summary how your talks went via a more private channel?

[anyahelene]

On 7 March 2015 14:31:12 CET, Paul Klint notifications@github.com wrote:

Take care! Maybe a brief summary how your talks went via a more private
channel?

---

Reply to this email directly or view it on GitHub:
#767 (comment)

We're certainly very happy with his OOPSLE talk. I think he may even have mentioned Rascal once or twice...

[PaulKlint]

@anyahelene sounds good, thanks!