Stream: ideas

Topic: expect-fx alternate syntax

Joshua Warner (Feb 28 2023 at 02:48):

Currently there's expect-fx (IIRC?) - but I'd like to change that one for the same reason.

Brendan Hansknecht (Feb 28 2023 at 02:53):

ok

Notification Bot (Mar 07 2023 at 18:40):

A message was moved here from #ideas > more keywords in syntax by Richard Feldman.

Notification Bot (Mar 07 2023 at 18:40):

A message was moved here from #ideas > more keywords in syntax by Richard Feldman.

Richard Feldman (Mar 07 2023 at 18:44):

so the reason behind the expect-fx naming is:

• expect fx would be syntactically ambiguous with expect followed by a variable named fx
• expectfx would introduce a new language keyword, which would set the precedent that whenever we have to introduce a new type of expect (I think there's a decent chance we'll want to use these for optimizations, e.g. expect-tco) we have to introduce a new language keyword, which is always a breaking syntax change
• expect-whatever can always be introduced as a nonbreaking syntax change because you can never write expect-blah for any value of blah since expect as a keyword already can't be followed by a -

Richard Feldman (Mar 07 2023 at 18:44):

I'm open to alternative design ideas here!

Joshua Warner (Mar 07 2023 at 20:08):

I remember seeing something about a possible syntax to wrap around backpassing (similar to haskell's do notation) - could we just use expect + that new syntax?

Joshua Warner (Mar 07 2023 at 20:08):

The other thing that comes to mind is something like expect <- myTask

Joshua Warner (Mar 07 2023 at 20:16):

Supposing the 'do' like syntax is something like this:

with Task.await
  a <- myTask
  # ...

... then we could just allow that at global scope, and interpret any expects inside such a block as expect-fx's

Brendan Hansknecht (Mar 07 2023 at 20:21):

and interpret any expects inside such a block as expect-fx's

with Task.await
  a <- myTask
  v = isValid a
  expect v

I don't think that is an expect-fx. It is an expect That happens to run within a task.

Joshua Warner (Mar 07 2023 at 22:45):

Doesn't that accomplish basically the same thing? (at least, given the right interpretation of what a top-level 'with' block means?)

Brendan Hansknecht (Mar 07 2023 at 22:47):

Doesn't expect-fx require an input that will generated by the task? Cause expect-fx is about mocking out tasks.

Brendan Hansknecht (Mar 07 2023 at 22:47):

In this case, I would assume either, this expect is invalid, or it can happen at runtime as a verification.

Brendan Hansknecht (Mar 07 2023 at 22:47):

If at runtime expect-fx doesn't make any sense.

Brendan Hansknecht (Mar 07 2023 at 22:48):

but maybe I don't understand how expect-fx works.

Richard Feldman (Mar 08 2023 at 01:47):

oh expect-fx doesn't mock - it actually runs the task for real!

Richard Feldman (Mar 08 2023 at 01:48):

for the (planned but not yet implemented) simulated tasks, ordinary expect will most likely work fine

Richard Feldman (Mar 08 2023 at 01:48):

the point of expect-fx is when you actually want to run your effects during tests, e.g. you want to create a real tempfile, write to it, etc.

Richard Feldman (Mar 08 2023 at 01:49):

since they use the host, they each have to be run in their own separate process so that if they segfault (for example) it won't take down the whole test runner

Brendan Hansknecht (Mar 08 2023 at 01:51):

oh, I miss understood expect-fx then. Cool. Thought it was roc only and didn't depend on the host.

Richard Feldman (Mar 08 2023 at 01:54):

yeah hopefully we can just use normal expect for the version that doesn't use the host, but we'll see when we get to the implementation stage on that! :smiley:

Joshua Warner (Mar 08 2023 at 03:15):

What if we made the side-effecting tests and mocked out tests the same thing? i.e. by default, running a new side-effecting test will run the side effects and automatically record all the tasks executed / results-of-host-calls into a file (which you're expected to check into your repo). All further test runs will by default run the test in fully-sandboxed mode, simply relying on the checked-in file.

Joshua Warner (Mar 08 2023 at 03:17):

If the test diverges from the expectation, you could (depending on config):

• Fail the test, alert the user
• Fall back on a mock implementation of the platform to provide results
• Automatically re-execute with side-effects (capturing the new result)

Richard Feldman (Aug 17 2023 at 18:26):

what if we called it expect.fx?

Richard Feldman (Aug 17 2023 at 18:26):

so it looks like normal roc syntax

Richard Feldman (Aug 17 2023 at 18:28):

it'd be a bit unusual in that you can give an expression to expect and also give an expression to expect.fx - so it would kinda look like expect is "a function but also a record somehow" if it were a variable, but of course it's actually a language keyword (which syntax highlighting should make clear) so of course it doesn't follow the rules variables do

Anton (Aug 18 2023 at 12:24):

expect.fx does not seem like it would address the original concerns of @Joshua Warner mentioned here.

Richard Feldman (Aug 18 2023 at 13:16):

yeah so I haven't tried it out yet, but I suspect the way we actually want lexing of identifiers to work, it will be better if we don't lex dots separately, but rather give the parser the entire contiguous foo.Bar.Baz.blah.0.1 and then parse that string one character at a time

Richard Feldman (Aug 18 2023 at 13:18):

because if the lexer emits tokens for dots, and it doesn't emit spaces, then the parser sees IDENT, DOT, IDENT for each of foo.bar, foo .bar, and foo . bar, and then it needs to do special things to distinguish between those cases because they're all supposed to parse differently

Richard Feldman (Aug 18 2023 at 13:19):

in the alternate design, where the entire chain of dotted things is one IDENT, then the parser sees expect.fx as a single token, and it's trivial to recognize it as a keyword

Richard Feldman (Aug 18 2023 at 13:19):

(just like any other keyword, which would be handled the same way)

Brian Carroll (Aug 18 2023 at 20:13):

Richard Feldman said:

it would kinda look like expect is "a function but also a record somehow"

I have an intuitive negative reaction to this because my brain has trouble parsing it even if the compiler doesn't. It doesn't fit into some existing pattern in the language so it is complicating my mental model.

Brian Carroll (Aug 18 2023 at 20:14):

So I think expect-fx and expectFx are both better for this reason

Last updated: Jun 16 2026 at 16:19 UTC