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

Unify Types and Expressions #31

Open
Victorious3 opened this issue Aug 7, 2023 · 1 comment
Open

Unify Types and Expressions #31

Victorious3 opened this issue Aug 7, 2023 · 1 comment
Milestone

Comments

@Victorious3
Copy link
Contributor

Victorious3 commented Aug 7, 2023

Right now the parsing of types and expressions is entirely separate. It is possible to resolve a type inside of an expression by using the type keyword, this makes it possible to pass types such as references to a generic function accepting a type.

def for_type(type T)

for_type(type &int)
for_type(type *int)

Since the type is resolved during typechecking it knows that the subtree is supposed to be a type anyways.
If expressions and types weren't separate you could leave out the superfluous type keyword.

The other problem is that as it stands right now, there is no way to parse an expression inside of a type context. Therefore it is not possible for a (compile time) function or macro to return a type. Doing this would necessitate another keyword (like consteval) in order to embed an expression inside of a type.

The real solution would be to leave the interpretation of a specific subtree up to the typechecker.
That means in practice that the prefix operators & type and * type as well as [type], def (type) -> (type) and type | type become proper operators and get parsed as such, instead of resolving to FUNCTION_T, etc right away.

() -> () would clash with (proposed) lambda functions, so those would need a fat arrow => instead.
Although it might be possible to infer it from context again.

This should be decided on soon because it will influence the way the language evolves in the future.

@Victorious3 Victorious3 changed the title Unity Types and Expressions Unify Types and Expressions Aug 7, 2023
@Victorious3
Copy link
Contributor Author

This also fixes that case: 10 !uint | 20
Right now the types bind higher than anything else, but with ! having a higher precedence than |,
this can be parsed as (10 ! uint) | 20 which is probably what was intended.

@Victorious3 Victorious3 added this to the 0.5 milestone Nov 17, 2023
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