I thought I'd add here some examples of repl interactions that I found surprising and would like to understand them better.
When I enter 1
in the repl, I get back 1 : Num * # val1
I next enter 2
, I get back 2 : Num * #val2
so far so good, nothing unusual.
I next enter val3 = 3
in the repl which gives back 3 : Num * #val3
as expected
I then enter 4
which gives me 4 : Num * #val3
yet typing in val3
still gives me back 3
Obviously the repl doesn't recognize that I already defined val3
, clearly it's a bug, nothing really surprising. Not sure if it's already been noticed before?
Another example that seem to be a bug to me but maybe it's not?
If I enter a type declaration and definitionx : F32
then x = 5
really any type would work, it doesn't matter.
Then I enter \x -> x
I get back a type of * -> F32
which seems odd to me. It suggests that the type checker has taken into account the x
variable I already defined earlier when inferring \x -> x
's type but the x
in the lambda is just the formal parameter's name, and the x
in the lambda's body is bound to the formal parameter. It shouldn't have anything to do with the top-level x
variable right?
Indeed if I enter \y -> y
where y
doesn't already exist as a top-level variable, I get back a -> a
as expected or \z -> z + 1
gives me Num a -> Num a
but \x -> x + 1
or \x -> x
gives me * -> F32
which I found surprising. It doesn't seem like it's doing the right thing here?
for that last problem: we don't allow shadowing, but it looks like that is not handled correctly
That's what I thought, shall I open an issue about the last problem? Is the first problem already documented?
I don't think it is, but I haven't worked on the repl in a long time. @Richard Feldman you did some recent repl work right?
in any case: yes please open issues. We'll deal with any duplicates
yeah those both look like bugs to me!
Here's a repl session from just now....What am I missing?
» x = 5
── MISSING FINAL EXPRESSION ────────────────────────────────────────────────────
I am partway through parsing a definition, but I got stuck here:
1│ app "app" provides [replOutput] to "./platform"
2│
3│ replOutput =
4│ x = 5
^
This definition is missing a final expression. A nested definition
must be followed by either another definition, or an expression
x = 4
y = 2
x + y
(That was the online repl)
I think you're missing indentation on tha tfinal line (line 4)?
No, it also happens with indentation, did we not implement our assignment magic in the web repl?
@Folkert de Vries ...not sure what you mean by missing indentation...I'm only writing: "x = 5" into the repl.
This looks like a bug in the web repl @Matthias Toepp, it does work on the local repl (roc repl
using a nightly release)
nightlies are available here btw
@Brian Carroll is this a regression in the web repl or do we still have to implement automatic handling of assignments that do not return anything?
should i open an issue for this?
(thanks @Anton )
should i open an issue for this?
yes please :)
ok...(i'm still impressed that there is an online repl! :)
opened issue: https://github.com/roc-lang/roc/issues/5301
I think the web repl has always been more picky about just doing assignment. It doesn't seem to keep state like the local repl. It needs every definition and the final expression all at once.
Maybe that is a regression. If so, it happened a while ago.
It's not a regression or a bug, it was just never implemented
The web repl and cli REPL have separate front ends, handle newlines differently, etc. The web repl currently only takes expressions, not definitions. The logic could be connected up but it hasn't been. Would be a great contribution if someone wants to do it!
I've found panics in the REPL when there are type mismatches:
Str.joinWith ", " ["Hi", "World"]
producesthread 'main' panicked at 'TODO turn fn_var into a RuntimeError Erroneous', crates/compiler/mono/src/ir.rs:4654:39
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Str.joinWith ["Hi", "World"] 42
producesthread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Erroneous', crates/compiler/mono/src/ir.rs:8875:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Found in the CLI REPL on ARM MacOS 13.4, using nightly 58067f9
(2023-06-02). Reproduced on the web REPL too. Couldn't find issues for these - should I open one?
should I open one?
Go ahead :)
There's also a panic in the CLI REPL when using undefined variables:
Str.joinWith [greeting, audience] ", "
"8\x9e\xf7\x05\x01"
thread 'main' panicked at 'Roc hit an error', crates/repl_cli/src/cli_gen.rs:133:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
This works as expected in the web REPL, printing the friendly UNRECOGNIZED NAME
message.
nice find, would love an issue for that one too! :smiley:
Then there's a lesser issue where the web REPL inserts a newline before executing code when enter is pressed. This produces an error message when the code before the cursor isn't a valid line for the REPL, eg.
Str.joinWith ["greeting", "audience"] ", "<cursor>
runs fine.
Str.joinWith ["greeting", "<cursor>audience"] ", "
produces UNFINISHED LIST
.
Str.joinWith ["greeting", "audience"] "<cursor>, "
produces ENDLESS STRING
.
Feel free to create issues, we prefer some accidental duplicate issues over unfiled issues
Done!
Last updated: Jul 06 2025 at 12:14 UTC