Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scope control directives #160

Open
skaller opened this issue Nov 10, 2020 · 0 comments
Open

Scope control directives #160

skaller opened this issue Nov 10, 2020 · 0 comments

Comments

@skaller
Copy link
Member

skaller commented Nov 10, 2020

Felix currently has a system where inherited symbols are available when a module (class) is opened, this puts them in the shadow scope of the opener as well as the public non-inherited symbols. If an inherited symbol is found by unqualified lookup, then it is resolved to the original symbol. Note this has to be done because the same symbol can be inherited two different ways and his is not an ambiguity. Also note this has to be done because open doesn't merely pull in a symbol:

open[T] X[T*T];
inherit [T] X[T * T];

each pull in a specialisation (of a whole class in these cases!).

However this has no impact on qualified name lookup which requires a symbol to be actually defined in the specified scope. So open is not transitive, inheritance is transitive, but in all cases, qualified name lookup is not impacted.

It is possible to introduce wrappers for types and functions which, being actual definitions, do impact qualified name lookup. I don't even remember what "use" and "rename" do but I think they do introduce new definitions though I'm not actually sure.

This leaves Felix without a systematic way to construct modules from others. This would be one way to reduce a lot of clutter. In Felix, there are no interfaces, so when you look at a module you see functions with their definitions. Also some are private and some public. Often we would like to make a set of small modules and then coalesce them as a way of hiding the private symbols. Wrappers are nasty because they do not respond well to additions or modifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant