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

Referencing architectures in code #25

Open
DasLixou opened this issue May 13, 2024 · 0 comments
Open

Referencing architectures in code #25

DasLixou opened this issue May 13, 2024 · 0 comments
Labels
A - Lang Area: Language Design P - Medium Priority: Medium S - Controversy Status: Controversy

Comments

@DasLixou
Copy link
Member

DasLixou commented May 13, 2024

Imagine this:

entity MyEntity { }
mod a {
    arch RTL for MyEntity { }
}
mod b {
    arch RTL for MyEntity { }
}

Absolute Unique Paths

Imports and lookup are handled the same as for all the other types, entities and modules.
This means that e.g. an RTL can only be defined once. We also can't allow having an arch name refer to multiple entities because then the end user might want to import a::RTL for EntityA, but b::RTL for EntityB. This would also make tracing the imports back way more complex.

use a::RTL;
use b::RTL; // ERROR: `RTL` already defined

arch .. {
    MyEntity(a::RTL) { // but I like the way they are refered to here.. and otherwise we could also introduce renaming on imports

    }
    MyEntity(b::RTL) {

    }
}

A downside of this is that multiple RTLs from different paths not having any overlapping entities still can't be refered to as by just RTL. You also can't make multiple RTL-named archs in the same module.

Absolute Overlapping Paths

Same as above, but now we allow having multiple overlapping imports making some stuff worse to trace back and identify.

use a::RTL;
use b::RTL; // We now allow this, because b::RTL might be for a completely else entity

arch .. {
    MyEntity(RTL) { // now the question is what RTL we use here?

    }
}

This has the upside of allowing something like this:

entity EntityA {}
entity EntityB {}
entity EntityC {}

mod first {
    arch RTL for EntityA {}
    arch RTL for EntityB {}
}
mod second {
    arch RTL for EntityA {}
    arch RTL for EntityC {}
}

use first::RTL for EntityB; // we could do a `for` syntax, which would check for overlapping archs with same entities.
use second::RTL for EntityA, EntityC;

Identifier per Entity

We don't import any arch. The name of an arch is unique in the whole compilation suite and is refered to by it directly.
The example from above wouldn't compile, but it would for two different entities.
A problem here is that when e.g. two libraries define a RTL arch for their own, it can't compile.

Work-bound identifier per entity

Same as above, but fixes the compilation problem by making it work-bound. e.g. work::RTL. Still not very tracable. Question is how that would work with multiple versions, reexports, etc.

@DasLixou DasLixou added A - Lang Area: Language Design P - Medium Priority: Medium S - Controversy Status: Controversy labels May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A - Lang Area: Language Design P - Medium Priority: Medium S - Controversy Status: Controversy
Projects
None yet
Development

No branches or pull requests

1 participant