Hey folks, I put together a quick skeleton for advent of code here https://github.com/drewolson/aoc-roc, a few questions
[ERROR][2024-10-19 13:35:51] .../lean/stderr.lua:74 "rpc" "/Users/drew/.local/bin/roc_language_server" "stderr" "An internal compiler expectation was broken.\nThis is definitely a compiler bug.\nPlease file an issue here: < https://github.com/roc-lang/roc/issues/new/choose>\nOutstanding references to the derived module\nLocation: crates/compiler/load_internal/src/file.rs:3299:29\n"
let me know if i should actually file a bug for this
i get the same error when i open https://github.com/drewolson/aoc-roc/blob/main/Aoc/Args.roc, which just consists of type synonyms
and final question 3. is there a library for arbitrary sized ints in roc?
One more observation -- i find it interesting that record builders are basically syntax sugar for applicatives using <-
, but that roc plans to deprecate backpassing, which is sugar for monads (among other things) using <-
this is the farthest i've gotten in writing a reasonably sized skeleton for aoc without hitting major compiler bugs, so that's awesome!
For 1
On line 65, you call Stdout.line! e
. That puts StdoutErr
as one of the possible error outputs. When mapping the errors, you have to map all possible errors. That includes the error produced there.
Weirdly, though, a catch all doesn't work
meaning if i instead have e -> e
i get a compiler error
actually, i guess i get a compiler bug :smile:
$ roc run
thread 'main' panicked at crates/compiler/mono/src/borrow.rs:396:34:
internal error: entered unreachable code:
No borrow signature for LambdaName { name: `16.IdentId(42)`, niche: Niche(Captures([InLayout(25), InLayout(44)])) } layout.
Tip 1: This can happen when you call a function with less arguments than it expects.
Like `Arg.list!` instead of `Arg.list! {}`.
Tip 2: `roc check yourfile.roc` can sometimes give you a helpful error.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
roc check main.roc
seems to think that i'm not narrowing the type at all https://gist.github.com/drewolson/c126c3a1981bcb15318dce6f95060d57
with the e -> e
arm rather than StdoutErr e -> StdoutErr e
oh, and i reproduced the LSP error like this
$ roc check Aoc/Args.roc
An internal compiler expectation was broken.
This is definitely a compiler bug.
Please file an issue here: <https://github.com/roc-lang/roc/issues/new/choose>
Outstanding references to the derived module
Location: crates/compiler/load_internal/src/file.rs:3299:29
Yeah, e -> e
does not narrow the type in roc.
That would be a form of gradual typing, which roc does not have
when err is
BadDayPart day part -> Exit 1 "Invalid day and part: $(Inspect.toStr day), $(Inspect.toStr part)"
BadInput path -> Exit 1 "Invalid input file: $(path)"
BadYear year -> Exit 1 "Invalid year: $(Inspect.toStr year)"
e -> e
Type of err
is [BadDayPart U8 U8, BadInput Str, BadYear U16, StdoutErr [...]]*
Type of the first three branches is [Exit U8 Str]*
Type of the final brach is the type of e
. The type of e
is the type of err
. So the type of the final branch is [BadDayPart U8 U8, BadInput Str, BadYear U16, StdoutErr [...]]*
unifying the branches, we get:
[BadDayPart U8 U8, BadInput Str, BadYear U16, Exit U8 Str, StdoutErr [...]]*
let me know if i should actually file a bug for this
Yes please for 2.
- is there a library for arbitrary sized ints in roc?
Not that I'm aware of, does I128 not fit your needs?
Anton said:
- is there a library for arbitrary sized ints in roc?
Not that I'm aware of, does I128 not fit your needs?
I128 may work, i’m just anticipating problems in advent of code designed to push towards very large ints
Anton said:
let me know if i should actually file a bug for this
Yes please for 2.
For posterity, this is done https://github.com/roc-lang/roc/issues/7175. I see you've already labeled it :smile:
drew has marked this topic as resolved.
Last updated: Jul 06 2025 at 12:14 UTC