Qualified binding operators vs. named binding operators

[gasche]

In #10979, @EduardoRFS proposes "named binding operators" to extend the binding operator from <keyword> <symbols> to <keyword> <symbols>? . <lident> : let.some or let*.option for example. Note that the "name" part (some, option) is simply a part of the identifier for the binding operator, it is not interpreted as an identifier it iself.

The motivation is to better support situations where several different monads/applicatives are mixed, and/or to make it less scope-polluting to define global binding operators at toplevel scope.

An alternative proposal that has been discussed is to allow to qualify binding operators with module paths: Option.let*, which would denote the identifier ( let* ) identifier in the Option module.

There are several points worth discussing.

Does allowing module qualification subsume named binding operators?

Let's assume we allow the syntax <module path> . <binding operator> for module qualification. Do we still see a need for binding operators, for example for disambiguation within the same module (using identifiers rather than less-clear symbols).

Maybe we want to consistently use let.map and let.bind instead of let+ and let*, and then Option.let.map, Option.let.bind?

Is the proposed qualified syntax confusing?

@Octachron remarked that there are two potential disambiguation rules for qualified binding operators: Option.let* x = t in u could desugar to either:

• a qualified lookup: ( Option.let* ) u (fun x -> t)
• a local open: let open Option in ( let* ) u (fun x -> t)

Everyone agrees I believe that the "qualified lookup" behavior is the right one. And there is little need for the local-open behavior for this syntax, as users can already write Option.(let* x = t in u) today. But @Octachron wonder if users could wrongly assume that this is a local open, and be surprised.

[dbuenzli]

Don't want to derail your thread but it is seems this question:

Should we provide more syntax to support a programming idiom that is known to compose poorly?

was never raised in the public discussion.

[lpw25]

Maybe we want to consistently use let.map and let.bind instead of let+ and let*, and then Option.let.map, Option.let.bind?

One thing I dislike here is the . in let.map. Everywhere else . between two words means that something is a subcomponent of something else. I'd rather see another separator e.g. Option.let/map if we do add this support. If you're going to go down that route, there is a reasonable argument for having let/map call map rather than something called (let/map). In which case it would of course be let/Option.map.

But @Octachron wonder if users could wrongly assume that this is a local open, and be surprised.

I suspect the answer to that is just "no, users could not wrongly assume that". It just seems like a very unlikely reading of that syntax.

[gasche]

let/map ...
and/zip ...
and/zip ...
in ...

actually looks nice. Did you just introduce a third syntactic proposal, after designing and proposing the current syntax for binding operators?

[EduardoRFS]

The analogy of . in my mind is not about sub-components, it is about accessing something, so the let.some would be accessing the Some side of the pattern. But I can see the interpretation of sub-components can arise, which still makes sense, you're accessing the possible subcomponent of an option, aka the content of the Some.

But I also agree that let/ascii makes sense. And it avoids any possible confusion with the ., my main concern here was not even about local open but a proper semantics for the . which seems hard.

[lpw25]

Did you just introduce a third syntactic proposal, after designing and proposing the current syntax for binding operators?

I actually think it is pretty reasonable to have both binding operators and a named binding syntax. Just as there are reasons to use + and reasons to use plus in different circumstances there are reasons to use let* and reasons to use let/bind in different circumstances. The stdlib probably needs to pick and choose one particular convention for monads, but it is fine for the language to leave room for users to make the choice themselves in their own code.

[haochenx]

One potential confusing aspect of this syntax form is that, if we let let/Option.map resolve to (1) Option.(let/map), there is an ambiguity for the user's perception of this syntax since the user could (understandably) instead assume that it resolves to (2) Option.map.

I have no good idea regarding mitigating this confusion since taking semantics (2) probably may defy the purpose of this syntax and are especially bad in the Option.map case as to be used as a binding operator, its arguments needs to be flipped.

[EduardoRFS]

On the proposal of Option.let* x = t in u I actually assumed at first that this was just a local open, I know that Option.(let* x = t in u) let already exists, but it seems like just an example of "let's omit the parens", like in many other places in OCaml.

[gasche]

On the other hand, foo.M.%(bar) is supported and it is not a local open, so there is precedent for using qualified user-defined operators in this way.

[haochenx]

I think Option.let+ ... has the disadvantage of breaking the beauty (?) of the current syntax: all let-variants literally start with a let in the current concrete syntax IIUC. This allows easy visual cues for finding let bindings and I think also helps formatters and indenters.

Also, Option.let+ ... looks like local open to me if not knowing intentions beforehand....

I'd like to give an upvote for let/map ... as suggested here. IMO, from the perspective of someone who's not familiar with this feature, this grammar form could be naturally perceived as some version of let while the map part likely not be a fixed part of the grammar but (could be) an identifier. Also, its qualified version e.g. let/List.map ... is very intuitive.

[yawaramin]

I would like to bring up a point here from a discussion in #2170

@gasche you said there:

We probably want to take the time to understand those [referring to this discussion] before adding binding operators in the standard library (ossifying on a particular approach).

Let's project what would happen if we were to merge the current state of that PR as it is today i.e. adding the Syntax submodule for each data type with the letops.

We could immediately use the letops just by doing e.g. open List.Syntax or let open List.Syntax in. Yes, it would be a new addition which would carry risk, but I think inherently no more than any new addition. We are already doing this with Lwt.Syntax and I don't think it has caused too much trouble.

If anything comes out of this current discussion to introduce more syntax about qualified binding operators (there's no guarantee this will happen), we can add the new ops at that time and (optionally) deprecate the Syntax submodules, to be removed in presumably OCaml 6.

I don't think this would be such a horrible outcome? Any thoughts?

[Octachron]

I don't think it is reasonable to forego discussions because we might be able to correct a mistake ten years later at the cost of breaking packages.

In particular, any new syntax can shift people preferences. My impression is that both Option.let* and let/option have the potential to subsume the need for a Syntax submodule.

[lpw25]

My impression is that both Option.let* and let/option have the potential to subsume the need for a Syntax submodule.

I think that is unlikely. The majority of monadic code works in a single monad and is it is clearer to make that choice once at the top of the code rather than restating it on every individual bind. ppx_let has support for doing let%bind.Foo and it is certainly used, but not as often as open Foo.Let_synax and let open Foo.Let_syntax in ....

[dbuenzli]

I find myself in agreement with @lpw25. FWIW I mostly work with the error monad and I'm unlikely to use either of let.result or Result.let*, it just eats too many of the 80 columns in which I need to express myself. I largely prefer to simply issue an open Result.Syntax at the top of my sources (or a short let (let*) = Result.bind at the moment).

[yawaramin]

I'll chime in to agree and add that, if letops are needed from multiple modules, I've always found a way to open them locally in small targeted scopes.

Look, I'm not suggesting to forego this discussion. I'm suggesting to have both discussions. Let-operators with symbols are not being removed from the language, right? They've been around since 2018, and libraries are starting to adopt them. The standard ones (let*, let+, and+) are the most recognized and widely known. Just because we might introduce some more syntax a year from now, doesn't mean the already-proposed Syntax submodule would be a mistake, right? If people are getting real benefit out of them in the meantime, it even takes the pressure off this discussion about qualified or named operators and lets it proceed at a regular pace.

Is OCaml philosophy to never break users? No, obviously not. Breakages can be introduced if there is a compelling reason. We don't know what will happen ten years from now. We might remove the Syntax submodule eventually in OCaml 6. Or we might not! In fact we might even un-deprecate it. We don't know. In the meantime, why not let people benefit from it?

[EduardoRFS]

I don't think it is reasonable to forego discussions because we might be able to correct a mistake ten years later at the cost of breaking packages.

I think most people would agree that a deprecation / breaking change is in fact reasonable in ten years especially because syntax changes can be mitigated with alternative modes for parsing, so it doesn't need to actually stop you from using such packages.

I've always found a way to open them locally in small targeted scopes.

Because I'm terrible at this communication thing and the original PR was written years ago, everyone seems to be thinking that a goal is to able to use multiple letops from multiple modules in the same place, that is not the case.

The main goal is to be able to have them available in a single namespace, avoiding the need for let open M.Syntax in, additionally adding the discoverability of monad transformer operators such as let/some_of_ok when in a result context and trying to bind an option monad.

Which I had the experience of seeing many times and needing to explain it while working on the Tezos codebase in the past.

[darioteixeira]

My two cents for this discussion:

1. The vast majority of the time I don't need more than one monad per function, and therefore I find myself perfectly happy with just doing a local open at the beginning of the function (e.g. let open Result.Syntax in) and then using the let* and let+ syntaxes within the function. The takeway from this is that the Stdlib shoud just provide Syntax submodules for Result, Option, etc, and the extra syntaxes under discussion are not really necessary and a bridge too far.

2. I'm also cognisant of the fact that syntactic convenience drives writing style, and therefore my observations from point 1 may suffer from Stockholm Syndrome...

[EduardoRFS]

Even if you're using a single let binding, let* is not intuitive, having a proper name would help most developers. This also avoids the need for combining operators instead of Result.let*? you can do let.ok_of_some or something like that.

One of the main advantages here is to allow for multiple let bindings to exist in the same namespace, avoiding the need for let open, it is not about using both on the same function, as that doesn't really work in a nice way without monad transformers.

[alan-j-hu]

I believe that named binding operators are necessary. Finding "meaningful" symbols is extremely hard. What does let+ mean? Choosing + for map and * for bind is arbitrary, and the operator names do not suggest anything about their meaning. (Worse, these names may carry unintended baggage about associativity or distributivity.) Haskell has <$> for map (which is supposed to resemble $, its function application operator) and >>= for bind (which is supposed to suggest a pipeline). Those operators are only slightly less arbitrary, but have at least managed to become a convention. Searching up symbols is also difficult. At least "map" and "bind" are searchable.

However, I agree with @haochenx in that I do not like the proposed syntax here that puts the module name before the let. OCaml's syntax is predictable because virtually all constructs begin with a keyword - fun, match, let, for, function. I read an article that recommends this syntax design (I believe it was about Rust or maybe F#) but I can't find it anymore. When reading code, coming across Option.let.map would be extremely jarring. I greatly prefer something like let/Option.map that puts the let first.

By convention, map and bind put the function parameter first for convenient partial application. However, the let operators desugar so the function comes second. So, if let/Option.map indeed desugars to a call to Option.map as @lpw25 suggests, should the function argument go first or second?

[gasche]

My current thinking is that I prefer the let/<longident> syntax, and I think we should implement that and gradually move away from binding operators. But I have not had the time to work on this myself lately, and I don't know when I would. If anyway wants to give a try to implementing let/<longident>-style extended binding forms, this would be nice.

[raphael-proust]

For professional reasons (the Tezos project) I use binding operators often. And our usage differs from some assumption that's floated around this thread. So here come a data point from a somewhat large project.

The majority of monadic code works in a single monad and is it is clearer to make that choice once at the top of the code rather than restating it on every individual bind.

We use both Lwt (because we need concurrency, we've needed concurrency for a long time) and Result (because we prefer when the type of a function is informative about possible failures). And unsurprisingly, we use the combination of Lwt+Result.

(We also use Option, and occasionally Lwt+Option, but we avoid Result+Option.)

We've tried a few things and we came up with some Syntax modules and some coding guidelines.

1. The choice of monad is at the level of the function. Each function starts with a let open Lwt_syntax in (or Result_syntax or Lwt_result_syntax). Only one monad syntax per function.
2. The syntax modules provide the common bits you would expect (let*, let+, return, etc.) as well as some more specific bits (fail when applicable).
   • The combined syntax module also provides let*? (to bind a result into the combined monad, ? is for the uncertainty of results) and let*! (to bind a promise into the combined monad). (It doesn't provide let+! nor let+? because that'd be too arcane.)

It works well in that:

• it's not too verbose, the binding operators are short, the open statement take one line per function
• which monad is in scope is explicit and is easy to find, generally it's on the same screen as the part of the code you are reading
• it allows to stick to the smallest monad which keeps the interfaces informative

---

(Personal opinion follows.)

Short operators and long-named functions are both useful in general. I think the same applies to binding operators. A short let* for the most common bind of the most common monad is nice. A longer let/result_into_option for less used combined-monad scenario is also nice.

[EduardoRFS]

Working at Tezos is exactly why I started this, especially for the combination of operators, it was quite annoying to teach some developers.

[EduardoRFS]

@gasche about let/<longident> I would rather do let/<lident> and possibly Option.let/map, in such a way that (let/map) is actually the identifier, this allows the same context to support many operations without adding random names like ok and some.

It also behaves like the other binding operators such as let* we could even allow for let*/ok which would be a nice extension from the current syntax.

[gasche]

To be clear, the previous proposal was to desugar let/foo x = t in u into foo t (fun x -> u), but instead of you are proposing to desugar into (let/foo) t (fun x -> u). (The first form expects quantification looking like let/M.foo, while the second supports M.let/foo.)

One point in favor of your proposal is that it paves the way to an extension for other keywords, such as match/foo (we have discussed match* in the past without reaching a consensus). Those would be much harder to express if all kwd/foo constructs are expected to somehow refer to the same foo identifier. Or, thinking out loud, we would need it to be a module, let/Foo, which exposes sub-functions for each supported syntactic form.

[EduardoRFS]

Yup, it is also compatible with my current usage where "return" is "foo" and bind "let/foo" so blocks like let/foo x = y in foo @@ x + y.