Consistency of type usage
See original GitHub issueSee https://github.com/langium/langium/pull/406#discussion_r810922786: we should validate usages of type
s for consistency. For example, this is not valid because Foo
is not an AST node type.
type Foo = string;
Bar returns Foo: ...
The same applies to actions and extended interfaces.
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
TYPOGRAPHY: Consistency
Consistency gives polish to a site and encourages visitors to stay by creating an expectation about the structure of a text.
Read more >Using consistent data types
You can largely avoid conversions by using consistent data types and by giving both operands the same usage and also appropriate PICTURE specifications....
Read more >haskell - What exactly makes a type system consistent?
In this sense of consistency, consistency means that the bottom (void) type doesn't have an inhabitant (and, thus, a derivation). That is, every ......
Read more >How Do You Stay Brand Consistent With Your Type Styles?
Consistent brands have and use their set typography style. The most successful type incorporates multiple header styles and one paragraph style.
Read more >Maintain Consistency and Adhere to Standards (Usability ...
To be easy to learn and use, systems should adhere to both internal and external consistency — they should use the same patterns...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@pluralia @msujew while working through this problem I had an idea I wanted to run by you both. Would it be considered reasonable to prevent interfaces from extending inferred types? And by extension, just saying that declared types cannot extend inferred types.
I have some thoughts why this might be helpful:
In this way, you can make something explicit, but you cannot set it back by basing it on something inferred.
I am trying to think if this restricts anything in terms of expressiveness, but I haven’t come up with anything yet 🤔 .
I like the idea, here is some thoughts.
We are going to implement the strict mode specially for the case.
We still have to do it for validation purposes.
One of the most important advantages of Langium is the brief prototyping: you can write a couple of parser rules and everything works out of the box. Sometimes you need to add declared types in addition to this pair of parser rules for minimal type shaping, in which case it’s no good to prohibit extending inferred types, because you would have to add more declared types, which goes against the idea of brief prototyping “as few entities in grammar as possible”.
Another point is that inferred and declared types will become semantically “unequal”: declared types can be extended, while inferred types cannot.
To summarize: I think we should do it in the strict mode only and allow it by default for brief prototyping.
We shortly discussed this problem, and @montymxb suggested using warnings when inferred types are extended by declared types. I fully support this idea: we keep prototyping brief, but at the same time notify the user when a declared type is “unstable” and can be implicitly changed because of the parent inferred type.