practical/practical-sa

The Practical Programming Language - Semantic Analyzer

practical-sa's Issues

Unify expression and statement parsing

The parser syntax should be able to start processing a block of code, and only then decide whether it is an expression returning value or a statement.

This is crucial for efficient nested compound statements support.

Should operators on literals delay range check?

def var : S8 = 0 - 128;

Should it not compile, because 128 is not a valid number for the expected type S8? In which case, the code needs to be written as:
def var : S8 = expect!S16(0 - 128);

Or should the check for range be delayed? How about:

def var : S8 = 128 - 256;?

Possible error in parsing: casts

cast!U32*(a)

According to the specs, shouldn't compile. Need to decide whether to fix the code or the specs.

Conditional expression does not propagate value range

A conditional expression always resets the value range it returns. It should unify the value ranges from left and right clauses.

Compile and run "Hello, world\n";

Get a working "Hello, world" program written in practical to run.

Implement operators

Implement operators and precedence.

Dummy run changes context

Determining an unconstrained expression by code-generating it using a dummy code-gen might introduce variables into the context (especially if it's variables defined in a parent context).

Invalid code gen on functions without return expression

def func() -> S32 {}

The above code should return a compile time error (not passing return value to function returning non-Void), but instead produces bad LLVM-IR code.

Use VRP to code-gen only the side of the `if` actually taken

If the result of the condition inside the if is known at compile time, we should only code-gen the then or else clause.

Consider necessity of IdentifierId

The code generation currently communicates an IdentifierId that identifies functions. It seems that it is never used, never even stored, and adds nothing to the code.

Should consider removing it.

Implicit cast compilation error is misleading.

When compiling the following code:
{
def var1: s32 = 5;
def var2: u32 = var1;
//Do something.
}

I get a compilation error along the lines of:
"s32 cast to u32 is not allowed"

This error is misleading as an explicit cast is allowed, it is just not allowed implicitly.

No error message on duplicate function definition in same module

When defining two identical (enough) functions in the same module, we cannot wait until linking time to complain about it.

Performance improvement of StatementList parsing

When parsing StatementList followed by an expression, the last expression may be parsed twice. Once as part of the StatementList, and another time on its own.

Implement type modifiers

Implement pointer types, arrays, and slices.

Conditional expression must be either alone or inside parenthesis

As currently implemented, conditional expressions must either come alone (i.e. - not interact with any other operator), or surrounded by parenthesis. So, this is legal:

def chain( number : U64 ) -> U64 {
  if( numer%2 == 0 ) {
    number/2
  } else {
    number*3 + 1
  }
}

And this is also legal:

def chain( number: U64 ) -> U64 {
  ( if(number>12) {number} else {12} ) + 5
}

But this isn't:

def chain( number: U64 ) -> U64 {
  if(number>12) {number} else {12} + 5
}

Currently, this is a limitation of the parser, but we need a debate on whether that's actually a good restriction on conditional expressions.

Value range of conditional expression resets to default

Instead, should check VR of the condition to see whether the result of the condition is compile-time known, and either pick the right one or merge the two.

VRP on operators should take the type's basic range into consideration

The VRP is calculated over a FullRangeInt. As such, the range calculated might be outside the result type's actual range.

VRP calculation should take the type's natural range into consideration.