Have assert be a language construct

[applejag]

What if assert was a statement built into the language?

Then when running something like this:

assert(1 == 2)

The error could be:

assertion failed: 1 == 2

Idea would be that the assert would print the raw source code of what was in the first argument position. So something like a function call would not suddenly show the return value:

assert(some_func() == 123)

So the error should be:

assertion failed: some_func() == 123

[myzie]

Just kicking around ideas...

If the existing assert built-in (link) could retrieve the stack trace and/or text of the current line of code, then it may not be necessary to make assert special in another way.

I may have looked briefly into making built-ins able to retrieve more runtime information, but it's been a long while, so I don't recall how hard or easy this might be right now.

[applejag]

One solution to maybe take inspiration from is C#'s CallerArgumentExpression attribute, which works something like this:

void Assert(bool condition, [CallerArgumentExpression("condition")] string conditionExpression = null)
{
    if (condition) return;

    throw new AssertException($"assertion failed: {conditionExpression}");
}

Assert(1 == 3); // throws AssertException("assertion failed: 1 == 3")
Assert(DateTime.Now == DateTime.UtcNow); // throws AssertException("assertion failed: DateTime.Now == DateTime.UtcNow")

This would require support to somehow annotate function fields, which would probably lead to a lot of changes, for a feature that might not be wanted.

It's I think also easier in C# as it's a completely statically typed language, so they can do this kind of stuff. Whereas at compile time the compiler might not know if a function call is pointing to the assert builtin function, such as with:

var x = assert

x(1 == 2)

I'm trying to think of a solution where the VM doesn't have to know about the AST or source code, but it's tricky. Because preferably the VM should be a standalone component, and should not depend on the AST at all.

[applejag]

Another source of inspiration could be F#'s approach to use dedicated syntax to capture the AST:

open Microsoft.FSharp.Quotations
open FSharp.Linq.RuntimeHelpers

let expr : Expr<int> = <@ 1 + 2 @>
let eval q = LeafExpressionConverter.EvaluateQuotation q

printfn "Expression: %A" expr
printfn "Evaluated: %A" (eval expr)

Which outputs:

Expression: Call (None, op_Addition, [Value (1), Value (2)])
Evaluated: 3

https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/code-quotations

Maybe this is an approach, to have dedicated syntax to capture an expression?

Such as, what if one of these were valid Risor?

# Special argument syntax
assert(@{ 1 == 2 })
assert @{ 1 == 2 }

# What if "func" contained the AST info?
# The syntax is a bit clunky, but what if `@{ ... }` was syntactic sugar for `func() { ... }`?
assert(func() { 1 == 2 })

# Special calling syntax, that just captures AST of all the arguments
@assert(1 == 2)

someObj := { "myAssert": assert }
someObj.@myAssert(1 == 2)

[applejag]

Another idea is to only rely on source code references in stack traces, something that lots of languages rely on.

So that this:

assert(1 == 2)

Turns into this:

$ risor example.risor
assertion failed
 --> example.risor
  |
1 | assert(1 == 2)
  | ^ here

One problem I have with this approach in a lot of other languages is when this stack trace is color highlighted to more than the "assertion failed" message you provided. As a result, your eye goes first to look at the assert string format argument instead of the rendered/formatted string output.

For example:

var my_var = 123

assert(my_var == 456, 'got {my_var}')

Turns into this:

$ risor example.risor
assertion failed: got 123
 --> example.risor
  |
3 | assert(my_var == 456, 'got {my_var}')
  | ^ here

The example source code view I have here gives more focus on the source code than the error message itself. To see what the actual value of my_var was, you have to search the output a little to actually see the got 123 part. If the output is also colored, then it might become even trickier to see.

So with an approach like this, the source code preview should be something like "bright black" (in ANSI basic terminal color terms) to not capture your eye too much.