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

Suggestion: advanced control on Label/Symbol visibility (GLOBAL?) #37

Open
StanHash opened this issue Feb 9, 2019 · 2 comments
Open

Comments

@StanHash
Copy link
Member

StanHash commented Feb 9, 2019

One of the notable shortcomings with the current label/symbol scope system is that it becomes impossible to "expose" a symbol globally once inside a scope, which may be a useful feature to have in some situations.

For example, let's say I am writing a set of public asm functions (that you may refer to in other parts of your source), but for the sake of writing clean code, those functions also call a bunch of other functions that I'd rather keep private (as they may have undefined behaviour outside, or just because I value encapsulation, or I don't want to pollute the global namespace, or something). Right now we don't have any way of mixing scoped and un-scoped label definitions like that without limiting workarounds. (Note: this can be achieved quite naturally by writing all of that in a single asm file and generating events with lyn but that's not always a convenient option and doesn't work for cases where complex hooks may be involved (requiring manually written events)).

So what I'm thinking of suggesting is some kind of specifier keyword (GLOBAL?) you'd add to a label definition (and probably later general symbol assignment):

GLOBAL Label:

Or

Label GLOBAL:

Or something else (Whatever feels the most right/works best with the rest of the language). That would put that label into the top-level scope regardless of the current scope.


Other symbol and scope related ideas

(since I'm on the subject and have some ideas)

  • "weak" label/symbol definitions, which would allow itself to be overwritten by any other (non-weak) symbol definition (even if before in the source). Maybe would use a WEAK keyword in the same way GLOBAL would be used.
  • "named scopes" (or "namespaces" whatever term works), where you could access a scoped symbol by using its name and any parent scope names (probably using the dot as a separator, as it is already a fairly common notation in a lot of languages for name resolution). You'd maybe declare a named scope by just putting an identifier before it's opening brace? Maybe this would break existing things so idk.
  • "global scopes" where all symbols declared in that scope would be as if declared in the toplevel scope (this could be useful for use with tool outputs and such, where the user doesn't necessarily have the ability to declare labels output by those global).
@Crazycolorz5
Copy link
Member

Crazycolorz5 commented Feb 22, 2019

Perhaps the python system of normal/nonlocal/global (as it pertains to function scope) would be ideal here:
https://www.programiz.com/python-programming/global-local-nonlocal-variables

Basically unmodified labels are as they are now. Nonlocal prior to a label exposes it one scope outwards to where it the declared. Global is obvious.

Then your asm example could be coded as

{
NONLOCAL myFunc:
(blah)
BL(mySubroutine)
(blah)
mySubroutine:
(blah)
}

(or global if you so choose)

@Crazycolorz5
Copy link
Member

fwiw I don't like the idea of types of scopes and due to the static, single-pass nature of EA, re-assignment and namespaces are a bad idea imo

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

2 participants