Qualified binding operators vs. named binding operators #12015

gasche · 2023-02-17T08:09:14Z

gasche
Feb 17, 2023
Maintainer

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 · 2023-02-17T08:49:54Z

dbuenzli
Feb 17, 2023
Collaborator

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.

0 replies

lpw25 · 2023-02-17T16:51:31Z

lpw25
Feb 17, 2023
Collaborator

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.

4 replies

gasche Feb 17, 2023
Maintainer Author

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 Feb 17, 2023

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 Feb 19, 2023
Collaborator

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 Feb 19, 2023

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 · 2023-02-17T22:51:44Z

EduardoRFS
Feb 17, 2023

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.

1 reply

gasche Feb 18, 2023
Maintainer Author

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 · 2023-02-19T20:42:43Z

haochenx
Feb 19, 2023

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.

0 replies

yawaramin · 2023-02-20T04:01:59Z

yawaramin
Feb 20, 2023

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?

0 replies

Octachron · 2023-02-20T09:53:15Z

Octachron
Feb 20, 2023
Maintainer

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.

4 replies

lpw25 Feb 20, 2023
Collaborator

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 Feb 20, 2023
Collaborator

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 Feb 20, 2023

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 Mar 16, 2023

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 · 2023-03-15T13:37:23Z

darioteixeira
Mar 15, 2023

My two cents for this discussion:

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.
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...

1 reply

EduardoRFS Mar 16, 2023

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 · 2023-07-28T22:10:02Z

alan-j-hu
Jul 28, 2023

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?

0 replies

gasche · 2023-10-25T08:09:15Z

gasche
Oct 25, 2023
Maintainer Author

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.

0 replies

raphael-proust · 2024-01-04T13:10:33Z

raphael-proust
Jan 4, 2024

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.

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.
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.

1 reply

EduardoRFS Jan 4, 2024

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

EduardoRFS · 2024-01-04T17:50:44Z

EduardoRFS
Jan 4, 2024

@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.

2 replies

gasche Jan 5, 2024
Maintainer Author

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 Jan 5, 2024

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.

gasche · 2024-07-20T21:05:41Z

gasche
Jul 20, 2024
Maintainer Author

I am interested in restarting this conversation, and opened a new PR #13325 which is a reboot of @EduardoRFS' #10979 with let/map, let/bind etc.

One aspect that I still feel ambivalent about is the extension to module-qualified operators. For example:

Do we write Option.let/map, or let/Option.map? (See previous comments: Qualified binding operators vs. named binding operators #12015 (comment) , Qualified binding operators vs. named binding operators #12015 (comment) ). If we choose the first one, do we also allow Option.let*?

Note that there is a precedent with qualified indexing operators, where x.!(y), which desugars into ( .!() ) x y can be qualified as x.M.!(y), which desugars into M.( .!() ) x y.
If we have let/map ... and/map ... in ..., does the qualification on the let also apply to the and? Should we wrie
```
Option.let/map x = foo
and/map y = bar
in baz
```
or rather
```
Option.let/map x = foo
Option.and/map y = bar
in baz
```
? (Clearly the latter is more regular and more general, but also significantly more verbose.)

7 replies

gasche Jul 21, 2024
Maintainer Author

My personal take-away from these examples:

Qualified binding operators are fairly verbose and their benefits over local open is not impressive. I think that it is reasonable to push for named binding operators (which I do find nice/clearer) even in absence of support for qualification.
Cascades of let* are more common than sequences of let+ and and+, so the idea of having the quantification on let+ implicitly carry over and+ is not that convincing in practice. It sounds like a good idea in purely applicative scenarios (no let*), but when mixing let* (or Inferno's let@) and let+, and+ it creates a jarring inconsistency and does not bring much in terms of concision. Plus it is more complex / more surprising / less discoverable. I will drop this idea of implicit quantification of and completely.

gasche Jul 21, 2024
Maintainer Author

Another take-away:

I thought that the form Mod.let<op> would be ugly due to having a module before the keyword. In fact, looking at examples, personally I think this is fine, especially thanks to syntax highlighting that helps keep the visual emphasis on the keyword part. I think that we would get used to this syntax quickly.

dbuenzli Jul 21, 2024
Collaborator

Assuming a Term_syntax module,

Note, the Cmdliner.Term.Syntax module exists since v1.3.0.

I have reservations about what you are proposing here but I already expressed them in the other discussions, so I don't think they are worth telling them again. But since you mention the verbosity: I don't see myself use what you are proposing here. It takes up too much of my scarce 80 columns for something that you repeat over and over in sequences of lets.

gasche Jul 21, 2024
Maintainer Author

I haven't found a trace of your past reservations. I went back to read your comments in #2170 but I don't think they are that, usually it's hard to miss when you are reserved. Do you have a link/reference?

dbuenzli Jul 21, 2024
Collaborator

It seems there's a bit of discussion all over the place and I can't find them either :-) Maybe I thought about this and that comment. Personally I'd rather have the {Result,Option}.Syntax modules being established with the existing operators but I don't have Stdlib energy right now.

gasche · 2024-07-22T08:04:41Z

gasche
Jul 22, 2024
Maintainer Author

I tried to implement qualified binding operators like List.let+ or List.and/map on top of #13325, but there is a conflict in the grammar. If you see the code let+ x = foo M, then this can be continued in two different ways:

let+ x = foo M ... in ...      (* shift: M is part of an expression [foo M...] *)
let+ x = foo M.and+ ... in ... (* reduce: M is part of an 'and' construct [M.and<op>]  *)

This is going to be a general problem for any syntax with qualified keywords Foo.Bar.keyword, where keyword was previously used by the parser as a lookahead word to structure the grammar. Now this decision is delayed to after reading <longident> DOT, so we would need an arbitrary deep lookahead to find the keyword to make parsing decision.

(An alternative would be to parse the longidents at the level of the lexer, rather than the parser. But it is conceptually ugly and we haven't needed to do this yet, which suggests that something fishy is going on.)

0 replies

Qualified binding operators vs. named binding operators #12015

Uh oh!

gasche Feb 17, 2023 Maintainer

Does allowing module qualification subsume named binding operators?

Is the proposed qualified syntax confusing?

Replies: 13 comments · 20 replies

Uh oh!

dbuenzli Feb 17, 2023 Collaborator

Uh oh!

lpw25 Feb 17, 2023 Collaborator

Uh oh!

Uh oh!

gasche Feb 17, 2023 Maintainer Author

Uh oh!

Uh oh!

lpw25 Feb 19, 2023 Collaborator

Uh oh!

Uh oh!

Uh oh!

gasche Feb 18, 2023 Maintainer Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Octachron Feb 20, 2023 Maintainer

Uh oh!

Uh oh!

lpw25 Feb 20, 2023 Collaborator

Uh oh!

dbuenzli Feb 20, 2023 Collaborator

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gasche Oct 25, 2023 Maintainer Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gasche Jan 5, 2024 Maintainer Author

Uh oh!

Uh oh!

gasche Jul 20, 2024 Maintainer Author

Uh oh!

gasche Jul 21, 2024 Maintainer Author

Uh oh!

gasche Jul 21, 2024 Maintainer Author

Uh oh!

gasche
Feb 17, 2023
Maintainer

Replies: 13 comments 20 replies

dbuenzli
Feb 17, 2023
Collaborator

lpw25
Feb 17, 2023
Collaborator

gasche Feb 17, 2023
Maintainer Author

lpw25 Feb 19, 2023
Collaborator

gasche Feb 18, 2023
Maintainer Author

Octachron
Feb 20, 2023
Maintainer

lpw25 Feb 20, 2023
Collaborator

dbuenzli Feb 20, 2023
Collaborator

gasche
Oct 25, 2023
Maintainer Author

gasche Jan 5, 2024
Maintainer Author

gasche
Jul 20, 2024
Maintainer Author

gasche Jul 21, 2024
Maintainer Author

gasche Jul 21, 2024
Maintainer Author