Roc CLI workflow

[lukewilliamboswell]

Zulip discussion thread

At present there are various commands and options for working with the Roc CLI. The difference in behaviour between options can be unclear, e.g. roc run verse roc dev.

The motivation behind this change is to align the behaviour of the CLI around two primary workflows, while still providing flexibility to use the available features through the use of flags.

1. RUN WORKFLOW we prioritise ease of use and productivity for the application author. This workflow is most useful when developing a script or application. Scripts and applications will run even if they are invalid and crash at runtime instead of at compile time. Assertions using inline expect will be checked, and dbg values are printed to stderr. The compiler defaults to using the development backends and surgical linker when available as this will build faster, at the expense of runtime performance.
2. BUILD WORKFLOW we prioritise safety and performance of the produced executable or library. This workflow is most useful when building an application for packaging and distribution. Applications will not build if they are invalid and there are any errors, though warnings are still printed. Inline expect or dbg are ignored and stripped from the produced binary. The compiler defaults to using the LLVM backend with full optimisations.

This task is to modify the Roc CLI workflows as follows;

RUN WORKFLOW

• The command is roc (modified from current implementation)
• Prioritise ease of use and productivity, panic/crash at run time
• Run using dev backends by default (fallback to llvm without optimisations)
• Prints Errors and Warnings
• Prints dbg values
• Proceed to run an invalid program
• Check inline expect assertions and panic/crash if any fail
• Supports scripting use-case with !#/usr/bin/env roc
• Note roc run and roc dev commands removed as redundant

BUILD WORKFLOW

• The command is roc build (modified from current implementation)
• Prioritise safety and performance, panic/crash at compile time
• Build an executable using llvm with full optimisations by default
• Print any Warnings
• Reports any Errors and will only build a valid program
• Ignores dbg and strips from binary
• Ignores expect and strips from binary

FLAGS

Below are some of the changes to flags that are related to this change.

• --watch (new flag) (re)compile binary on any changes in the application [NOTE this flag needs further discussion and should be left for a future task]
• --backend <llvm/dev> (new flag) compile binary using llvm or dev backend instead of default
• --opt <none/size/speed> (new flags)
  • --opt none compile without optimisations, llvm only
  • --opt size (renamed from --opt-size) smaller binary, llvm only
  • --opt speed (renamed from --optimize) compile with optimisations, llvm only

[lukewilliamboswell]

Additional guidance for this task

https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/Roc.20cli.20workflow/near/451019171

[DavidEdwards1]

Hey @lukewilliamboswell, is this issue up for grabs/still relevant? 🙇

[lukewilliamboswell]

Yes very much still relevant and planned. Most of this is currently waiting for someone to implement the changes.

I'm thinking we might want to make this a tracking Issue and spawn off a couple of other issues for parts of this. The original description needs updating from Richard's additional comments in that zulip thread. I can look at this later today -- though any help updating this or scoping out and thinking of good sub-issues is also appreciated. It might be best to coordinate this part on zulip, are you active over there?

If you make any changes related to this, I recommend you do so from the #6859 branch (either PR into that branch, or main once that lands) as there has been some related cleanup in that PR which makes this work much easier to implement. My plan was to start chipping away at these features once that PR lands. It's very close now so no reason to wait any longer.

[DavidEdwards1]

Yeah 💯 breaking it up a bit sounds good 👍 I am on the Zulip, shall we have a new thread or continue on the previous one?

[lukewilliamboswell]

Yeah 💯 breaking it up a bit sounds good 👍 I am on the Zulip, shall we have a new thread or continue on the previous one?

I think we should continue the discussion... it's easier to look back and see the previous conversation and remind ourselves of what we were thinking. 😃

Thanks for looking into this.