Jonathan Kelly (Mar 02 2025 at 22:26): Jonathan Kelly (Mar 02 2025 at 22:26):Where is best place for (what appear to be) documentation fixups?
in https://www.roc-lang.org/builtins/Num#neg section, there's a code snippet
Frac.pi |> Num.add(1.0)
which gives an error, but
Num.pi |> Num.add(1.0)
gives the answer.
Luke Boswell (Mar 02 2025 at 22:27): Luke Boswell (Mar 02 2025 at 22:28):Looks like there's a few other places in that file where we use Frac.pi also
Jonathan Kelly (Mar 02 2025 at 22:34):While I'm here ... Num.sqrt(4.0) seems to crash the repl ... ?
not just the repl ...
app [main!] { pf: platform "https://github.com/roc-lang/basic-cli/releases/download/0.19.0/Hj-J_zxz7V9YurCSTFcFdu6cQJie4guzsPMUi5kBYUk.tar.br" }
import pf.Stdout
main! = |_args|
Stdout.line!("sqrt 2.0 is ${Num.to_str(Num.sqrt(2.0))}")
thread 'main' panicked at crates/compiler/gen_llvm/src/llvm/lowlevel.rs:2236:13:
internal error: entered unreachable code: Unrecognized dec unary operation: NumSqrtUnchecked
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
oh ...
if you
Num.sqrt(4.0f64)
it runs ok.
Luke Boswell (Mar 02 2025 at 22:37):Yeah that's strange...definitely a bug
Jonathan Kelly (Mar 02 2025 at 22:43):If you don't specify a type, Roc will default to using Dec because it's the least error-prone overall.
... except when it's not. :blush:
Luke Boswell (Mar 02 2025 at 22:57):The REPL uses the dev backend -- which was never fully implemented, so there are some sharp edge cases like this around.
Luke Boswell (Mar 02 2025 at 22:58):I think with the new approach in our zig compiler we won't have these kind of issues... because everything will be using the same interpreter
Last updated: Jul 05 2025 at 12:14 UTC