Add assert statements

[TobiasWrigstad]

Please add two assert statements:

assert_false(expr, msg)
assert_true(expr, msg)

I prefer that msg be optional.
I also prefer that if possible, msg can be a printf-style string with {} interpolation markers so that I can write

assert_true(x > 0, "Expected x > 0, was {}\n", x)

Preferably even without having to explicate the \n at the end, too!

(Yes, I realise that by allowing expressions which may fail in asserts the asserts may not print fine etc.)

[EliasC]

Since we have not nowadays, maybe just an assert would do?

[TobiasWrigstad]

Yes and no. I am a fan of clarity here. And it is more complicated to insert an operator and brackets in the right place than to write false explicitly.

It costs very little to add once you have assert_true so why not support it too?

[EliasC]

The big caveat here is that everything we add right now must be chained through each layer of the compiler, from the parser to the code generation. We're not extending some library, but the compiler itself. The more convenience functionality we add right now, the more we will need to maintain at a later stage. When we have module support, we can do some things through libraries instead.

What we could do is to have a single Assert node in the AST and let the parser figure out what its parameters should be (i.e., if we're expecting true or false).

[TobiasWrigstad]

Let’s move this discussion to email.

[supercooldave]

You could add an abort statement to the AST. The rest can be done via a transformation.

We probably need to start thinking if a standard lib/prelude with such definitions, even if it is naked into the compiler for now.

Sent from my iPhone

On 08/08/2014, at 10:18, EliasC notifications@github.com wrote:

The big caveat here is that everything we add right now must be chained through each layer of the compiler, from the parser to the code generation. We're not extending some library, but the compiler itself. The more convenience functionality we add right now, the more we will need to maintain at a later stage. When we have module support, we can do some things through libraries instead.

What we could do is to have a single Assert node in the AST and let the parser figure out what its parameters should be (i.e., if we're expecting true or false).

—
Reply to this email directly or view it on GitHub.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[EliasC]

@supercooldave An abort command is a good idea. I'm going to add a de-sugaring pass to the compiler to try to make additions of functionality a bit more light weight.

[supercooldave]

Maybe there could be a file of "standard definitions" that could be scooped up by the compiler. This would avoid the need for a lot of standard things being baked into the compiler, especially with embedded C.

Sent from my iPhone

On 08/08/2014, at 10:56, EliasC notifications@github.com wrote:

@supercooldave An abort command is a good idea. I'm going to add a de-sugaring pass to the compiler to try to make additions of functionality a bit more light weight.

—
Reply to this email directly or view it on GitHub.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[EliasC]

I've added a desugaring pass to the compiler (see ir/AST/Desugarer.hs). This allows us to add certain functionality without bloating with the parser. For example, there is an Exit node in the AST, but no case for it in the parser. Also, there is support for assertTrue and assertFalse, but no traces of it in the parser, typechecker or code generation.

So far it generates terrible error messages since the typechecker works with the desugared AST, but I guess we can live with that for now. One possible way around it is to let desugared nodes have a reference to the thing it was desugared from, and somehow letting the error message refer to this instead of the actual AST.

@TobiasWrigstad, I'm assigning you to try the desugarer out by adding the cases for formated error printing (please close this issue when you're done).

[TobiasWrigstad]

:)

[TobiasWrigstad]

All of the above supported as of now.