-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Labels
nextFuture updates to the spec not implementable for the current yearFuture updates to the spec not implementable for the current year
Description
Motivation
We need some way of handling expressions that are evaluatable at compile time but that affect runtime behaviours. Consider the following examples:
integer size = 2+3;
integer[5] v1; // uninit ct-sized -> OK
integer[*] v2; // uninit infered-size -> CT SizeError
integer[*] v3 = 1..2; // init infered-size -> OK
integer[size] v4 = 1..5; // init rt-sized -> OK
integer[size] v5 = 1..4; // init rt-sized -> RT SizeError
integer[size]; // uninit rt-sized -> DONT KNOW !Only on the integer[size] declaration would we fail, this is because we currently do not propagate constant expressions through the AST. This is particularly problematic in the global scope, where we have to define constants that could have size evaluated from other constants. Consider the above example in the global scope, what would the correct behavior be.
Tasks
- Precisely define what a constexpr is in gazprea.
- I would propose some definition like "any expression computable at compile time using only scalar constants" or some such.
- Are there grammar changes we need to make?
- perhaps we add a specifier
constexprfor some expressions to be evaluated at compile time?
- perhaps we add a specifier
- Ensure that this does not encourage front-end optimization of the language.
- To that end, this might just be a bad thing to add to the language, since we are fundamentally teaching students how to build a front-end.
- Maybe we teach students how to use the LLVM annotations to tell LLVM to do the analysis and offload the responsability
Metadata
Metadata
Assignees
Labels
nextFuture updates to the spec not implementable for the current yearFuture updates to the spec not implementable for the current year