Syntax sugar for open (a.k.a local open)

[believer]

I'm receiving an error when locally opening a module that I'm not sure how to handle

4 │  Runtime.onInstalled(_ => {
5 │    DeclarativeContent.(
6 │      removeRules(_ => {
7 │        addRules([
8 │          {

I'm not sure what to parse here when looking at "(".

The error highlights removeRules

[IwanKaramazow]

There's currently no syntax sugar for local open. We're looking into a solution. For now you can use:

Runtime.onInstalled(_ => {
  open DeclarativeContent
})

[jfrolich]

I think it might be great that there is no open sugar, as it's can be confusing, and making local opens more explicit isn't a bad thing imo.

[believer]

Ahh great, thanks @IwanKaramazow!

[alex35mil]

I think it might be great that there is no open sugar

Disagree here.

[alex35mil]

I would also be very happy if this would be possible:

let fn = () => Dom.{
  ...
}

[IwanKaramazow]

@alexfedoseev Yes, that's actually a valid use case. I would like to look into alternatives.

[bloodyowl]

Maybe we could take the old horrible JS equivalent-ish

with Cn ("one" + "two" + "three");

let fn = () => with Dom.Element {
  ...
}

[jfrolich]

I always found the local open syntax strange (never seen something like that syntax before) and hard to understand when learning Reason and reading code snippets. I think something like @bloodyowl suggestion reads much better for newcomers.

[tsnobip]

Local open adds parenses and indentation, overall quite a lot of noise in my opinion. I usually prefer to use open but refmt transforms it back to a local open 😑
Maybe we could do something like

open Belt, Dom, Element

If we want a terse syntax

[austindd]

This really isn’t about terse vs. verbose open statements. It’s about being able to use multiple, mutually exclusive opens at the expression level vs. the scope level.

Local opens allow us to be much more explicit about precisely where each module is being used/opened.

The normal open keyword will open the module for the entire enclosing scope, which is not always desirable. E.g. you might not be fully aware of which Array module you are using, or the fact that your logging function is actually streaming data to cloud storage instead of to the console on your local machine.

The only other way to confine the scope of a normal open is to wrap your expression in a new block scope, and open the module there.

Obviously using local open can get out of hand, just like any kind of module opening, but a good style guide can go a long way in helping people avoid cryptic code. And it’s not that hard to learn the syntax for it.

[IwanKaramazow]

@austindd it's unclear what direction local open should take at this point. Do you have more concrete example to illustrate your case?

[fhammerschmidt]

So now ReScript formats a lot of one-liners in our codebase into at least 4-liners, e.g.

let clone = date => Js.Date.(date->getTime->fromFloat);

to

let clone = date => {
  open Js.Date
  date->getTime->fromFloat
}

Something terser would be very appreciated.

EDIT: Local opens are actually a very important feature, because compared to the imports in JS, you only need to have some occasional opens on the top of the file. Now they are all over the place in ReScript, adding more noise to a codebase than some parens would do.