Stream: ideas

Topic: Love for top-levels in the repl

Ayaz Hafiz (Oct 08 2022 at 22:21):

I know we've talked before about ways to improve the repl, and I'd love for it to get some more love in the short term. What do folks think of this idea for supporting top-level definitions, so you can play around with things like abilities in the repl too?

• Whenever you enter something that looks like a definition, it will be parsed line-by-line until the definition is complete:

> myFunc =
>  <keep parsing>

when a definition is parsed as completed, print out the def name and its type

> myFunc =
>   \x -> x

myFunc : a -> a

this also supports multi-line aliases and abilities:

> MyAbility has
>   <keep parsing>

• Since abilities do not end with a single expression in the way that value definitions do, you have two ways to force the repl to stop parsing a definition, and either record the definition, or issue a parse error.
  • Option 1: de-indent the cursor, and press enter
  • Option 2: press enter three times. This way, you can still press enter twice to have blank lines in your definition; however, if you have two blank lines in a row, it's an indication to stop parsing.

> MyAbility has
>  f : a, a -> a | a has MyAbility
>
>

MyAbility : ability (Making this line up, it could be improved)

• When you enter something that can only parse as an expression, we evaluate the expression, and print out the output like is done today.

> myFunc 1

1 : Num *

• If you want to bail out of an expression without it being parsed and evaluated at all, you can do that with <Ctrl-C> (SIGINT) now.

• You'll be able to over-write definitions - if you do something like

> y = 1

y : Num *

> y = 2

y : Num *

Subsequent expressions that use y will use the second definition. However, ambiguous definitions, like conflicts during record destructuring, will be errors.

> {a, b} = {a: 1, b: 2}

{a, b} : {a: Num *, b: Num *}

> {a, c} = {a: 1, c: 2}

-- CONFLICTING DEFINITION --

`a` is defined in two separate record destructurings in this repl session, that don't each introduce the same variables.

I could see arguments against this though, for similar anti-shadow reasons as Roc files have. Curious what others think

These are small changes but I think they'll dramatically improve the QoL in the repl. Thoughts?

jan kili (Oct 08 2022 at 22:49):

Tiny proposal - every unassigned expression is assigned to an autogenerated variable name like some web browser dev tools do? Maybe var1, var2, etc.

jan kili (Oct 08 2022 at 22:49):

This saves copy/paste work when exploring expressions and wanting to reuse them

jan kili (Oct 08 2022 at 22:53):

Everything you proposed sounds great

Brian Carroll (Oct 09 2022 at 11:13):

For the online REPL, multi line input works differently. You type multiple lines into a textarea using Shift-Enter for newlines,, and then submit it all at once.

This is because the rustyline library doesn't work on the web so I decided to do something more "web native". There is some JS code to detect hitting the up and down arrows to go back through history.

The point is that the "hit enter 3 times" thing might be different. We might not need it.

Or alternatively we could change the way the online version works to be more like the CLI. That might be a bit more work to replicate anything rustyline does.

Ayaz Hafiz (Oct 09 2022 at 13:36):

Yeah that’s a good point Brian. Personally I think it would be nice if we could avoid shift+enter but I think it’s okay if the web and cli version are a bit different

Last updated: Jun 16 2026 at 16:19 UTC