Do blocks

[gustavopch]

👉 I think you're already working on something like this, but I'm still sending the proposal because it specifies a very important behavior with early-returns.

---

Sometimes you want to calculate a value with some intermediate variables and you want to limit the exposure of those variables as much as possible to ensure they're not used anywhere else. Look at ReScript's blocks for an example of such syntax: https://rescript-lang.org/docs/manual/latest/overview#blocks-1.

So I propose support for this:

fetchMenu := async () =>
  restaurant .= do
    response := await fetch(...)
    if !response.ok return null
    body := await response.json()
    body.restaurant

  products := do
    response:= await fetch(...)
    if !response.ok return null
    body := await response.json()
    body.products

  { ...restaurant, products }

Besides limiting the exposure of intermediate variables, it also makes the code more readable. At each indent level you have a different level of detail, so you can quickly see that in the second indent level you're doing basically 3 things:

1. Fetching the restaurant.
2. Fetching the products.
3. Returning merged data.

If you want more details, then you read what's inside each block. This is important because we spend more time reading code than writing, and this makes it easier to read.

Of course, it's also possible to extract those blocks into separate functions, but then you have to scroll up and down to change the level of detail you're reading. Reading from top to bottom, in the exact order it actually happens, is easier IMHO. It's like being able to zoom in and zoom out.

Note that transpiling the blocks to an IIFE wouldn't be enough because the idea is that any return inside the blocks make the fetchMenu function early-return, and a return inside an IIFE would actually return null to the variable but keep executing the function.

Edits

• 2023-01-07: Replace braces with do and indentation.

[STRd6]

Thanks for the great suggestion. I think this effectively boils down to having full support for BlockExpressions which is something we should aim for.

We can start by allowing them in simple cases (like the right hand side of an assignment) and expand to covering more and more cases.

A possible transpilation for your example

const fetchMenu = async () => {
  let restaurant
  {
    const response = await fetch(...)
    if (!response.ok) return null
    const body = await response.json()
    restaurant = body.restaurant
  }

  let products1
  {
    const response = await fetch(...)
    if (!response.ok) return null
    const body = await response.json()
    products1 = body.products
  }
  const products = products1

  return { ...restaurant, products }
}

[gustavopch]

BTW, can we somehow support both early-returns intended to exit the function AND early-returns intended to assign a value to the variable? Something like:

fetchMenu := async () =>
  // ...
  products := {
    response:= await fetch(...)
    if !response.ok return null // Exits `fetchMenu` with `null`
    body := await response.json()
    if !body.products break [] // Assigns `[]` to `products`, breaks from this block and continues to run the next lines of `fetchMenu`
    body.products
  }

In this specific case you could easily use a ternary or a nullish coalescing operator at the last line of the block, but sometimes you'll actually want to early-return a value to the variable.

Answered in #146 (reply in thread).

[edemaine]

Just a note that I'd like to also support the following syntax (with do and indentation, instead of braces) for the exact same idea:

fetchMenu := async () =>
  restaurant .= do
    response := await fetch(...)
    if !response.ok return null
    body := await response.json()
    body.restaurant

  products := do
    response:= await fetch(...)
    if !response.ok return null
    body := await response.json()
    body.products

  { ...restaurant, products }

As such I'd expect it to be more or less compatible with #58 and the do TC39 proposal. In particular, I think it's natural to support break inside a do, which I guess would return a value of undefined (whereas return jumps out). I think in this case we might need to wrap with an actual do { ... } while (false) block, but should be compatible with Daniel's transpilation above.

[gustavopch]

Agreed. Could we allow breaking with a value as I said here? #146 (reply in thread)

[STRd6]

Yes, break with values would be good to have 👍

[STRd6]

But it might need a different keyword to avoid colliding with break label... something to think about.

[gustavopch]

Some ideas to avoid adding new reserved keywords: break with <value>, do return <value>, escape <value>.

In ReScript, if you just write the value without a proper statement, it's interpreted as an implicit return (e.g. if !response.ok []). Not sure if it makes sense for Civet though.

[edemaine]

do blocks work now, except they use IIFEs, so return means "return this value from the do block" which is maybe not intuitive (I would have expected it to return from the function).

As @gustavopch suggested in #381 (comment), given #362, maybe do.value = value; break is the way to write break with value. With a bit more effort, this would be doable with the current do blocks.