roc-lang
Compiler crashes when type annotation is not provided
The following code crashes the compiler:
elemsApproxEq = \values, index1, index2 ->
val1 = List.get? values index1
val2 = List.get? values index2
Ok (Num.isApproxEq val1 val2 {})
The output is:
thread 'main' panicked at crates/compiler/gen_dev/src/generic64/mod.rs:1333:18:
not yet implemented: NumAbs: layout, Builtin(Decimal)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
It looks like it's because Num.isApproxEq is not implemented for the Decimal type. Shouldn't it crash only if the function is called with a list of decimals?
In any case, adding the following type definition before the function definition works around the issue:
elemsApproxEq : List F64, U64, U64 -> Result Bool
Shouldn't it crash only if the function is called with a list of decimals?
We default to Dec if Dec, F64, ... are possible to help users avoid typical floating point footguns.
Yes, that makes sense. However, my code only calls this function with lists of F64s, so I feel like it's still a bug, wouldn't you agree?
my code only calls this function with lists of F64s
Can you provide a repro? the error message indicates this is using a Dec.
Ah, actually I just realised that some test cases included floats without the f64 qualifier, so that's the problem, sorry for the noise.
However, I do get the issue in the REPL, if I just copy/paste the function definition above, before even calling it. I'm not sure whether that's expected?
$ roc repl
The rockin' roc repl
────────────────────────
Enter an expression, or :help, or :q to quit.
» elemsApproxEq = \values, index1, index2 ->
… val1 = List.get? values index1
… val2 = List.get? values index2
… Ok (Num.isApproxEq val1 val2 {})
thread 'main' panicked at crates/compiler/gen_dev/src/generic64/mod.rs:1333:18:
not yet implemented: NumAbs: layout, Builtin(Decimal)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I assume this is because the Dec is the default number type. I'm not sure though.
Ideally we would finish implementing all these missing Num functions in the dev backends.