Skip to content

[NEXT] Constexprs #79

@Sir-NoChill

Description

@Sir-NoChill

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 constexpr for some expressions to be evaluated at compile time?
  • 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

No one assigned

    Labels

    nextFuture updates to the spec not implementable for the current year

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions