The following expression:

@hi @ >-< @this is a random string concatenation@

Is being checked as invalid, although being valid as our specs says

PR #51 closed issue #5 and introduced modularized error handling. However, the error handler does not differentiate between parse errors and semantic errors, due to the fact that the category of an error is not handled when it's raised, but rather where it's catched, and both parsing and semantic analysis are done at the same time.

A suggestion would be for the error category to be part of the Error data type.

Currently it is a Constant

Add several ones and test them locally. Submit results on a PR.

• guards should have the same type as the switch argument
• If the guard type is TypeError not raise errors again

Right now, one possible error raised by running our compiler with the find_roots_polym_degree_two.souls sample file is:

The function call is being type-checked as its list of arguments, instead of its return type.

• Implement ascii_of for chars
• Implement ascii_of for strings (may require a garbage collector)

We need a way to initialize records using literals, something like a JSON or alike

Functions should check that return statements have expressions and their types should match with the function data type.

• malloc calls should expect only pointers
• free calls should expect only pointers

Currently we are not supporting enums

We need to centralize all compilers errors in the project, a file named Errors.hs with an only data type CompilerError that derives from Show would be ideal.

The errors that we need to handle are the following:

• Lexer errors:
  • "Did you mean this token instead of this?" kind of errors
  • General errors
• Parser errors:
  • For the moments, just a simple parse error
• Semantic errors:
  • Variable redeclaration on the same declaration block
  • Name not found:
    • For functions
    • For variables
    • For accesing properties that does not exists on a variable of type bezel or link.

Iterator variables are not taken into account for the moment for the semantic analysis

Firelink compiler should pretty-print the AST result

Replace our RWS.tell calls with a logError function that receives a message and a token

Currently, the following (clearly invalidly typed) programs raise no errors whatsoever.

hello ashen one

    traveling somewhere
    with
        var a of type humanity,
        var b of type hollow,
        var c of type bonfire
    in your inventory
        a <<= 1 \
        a <<= lit \
        a <<= 4.5 \
        b <<= 1 \
        b <<= lit \
        b <<= 4.5 \
        c <<= 1 \
        c <<= lit \
        c <<= 4.5

    you died

farewell ashen one

Assignments should be type-checked in order to ensure that the LVAL and RVAL types match, on compile time.

Procedure calls should type check the same way as functions call does

Some important, fundamental mathematical operations are missing, such as sqrt :: hollow -> hollow and pow :: hollow -> humanity -> hollow. It might be useful to add them, either as basic operators (at least for pow) or prelude functions.

the following program:

hello ashen one

requiring help of
    knight myAlias <1>-chest of type humanity
help received


traveling somewhere
with
    var myAlias of type myAlias
in your inventory
    with orange saponite say |a|
you died


farewell ashen one

will show an error on the var myAlias of type myAlias declaration, but the following one:

hello ashen one

requiring help of
    knight myAlias <1>-chest of type humanity
help received


traveling somewhere
    trust your inventory
    lit:
        traveling somewhere
        with
            var myAlias of type myAlias
        in your inventory
            with orange saponite say @haha@
        you died
    inventory closed
you died


farewell ashen one

LVALs should not be separate from other EXPRs. They should be properly type checked on assignments and memory dereferencing, as well as ref parameter passing.

We need a statement or something to know in an specific moment what option an union variable has. For example,

union {int a; char b} c;
c.a = 1; // the value on c.b is overriden
c.b = 'a'; // the value on c.a is overriden
if (c.a is active) ... else ...

• Traversed expression should be array or set
• Traversed expression should not be modified inside loop
• If type or traversed expression is container<T>, type of iterator variable should be T
• Iterator variable should not be modified inside loop

Firelink compiler must only print errors in case there are some, including context errors (already does for lexer and parser errors)

For example, when if/else guards are generated, the same goto is generated twice e.g.

goto 3
goto 3

[ ] unclosed "if" block
[ ] unclosed "switch" block
[ ] unclosed indetermined "for" block
[ ] unclosed determined "for" block
[ ] unclosed parenthesis
[ ] missing colon on while statement
[ ] missing colon on switch statement

• Assignments
• Read from stdin

Every aspect of TAC code generation for sets is missing. This might require a garbage collector.

Firelink compiler must allow the user to declare and initialize variables at the same time (required for consts), and the relevant declaration instructions must be added.

Currently, running our compiler with the test.souls file generates three errors, one of them being:

We should either fix the file or discuss if we should allow variables to be named as type aliases (I can't remember if we have already talked about this).

Just for id assignment, not index or dot expression.

• Specify that you can only perform I/O operations (read/print) on scalar types.
  • Also check/change type-checking in order to ensure this.
• Specify that structured iteration will be prioritized during development for lists.
• Fix: after iterations, the iteration variable will keep the last value used on the guard checking
• Check functions code samples (they're outdated)
• Fix typo on pointers specification
• Add size function for strings

• Use base + offset for vars
• Determine where to start saving temporals
• Use base + offset for temps

Firelink should support co-recursive functions

The following declaration block:

var x of type small humanity <<= 1,
var y of type small humanity <<= x

fails saying that the x variable in right side of y assignment was not declared, but it is obviously available