(>>) operator in Lwt?

I’m trying to get the hang of Lwt, and I’ve run into this old Gist.

I’ve taken some time to make it work but I’m having a problem with the >> operator on line 32. The compiler tells me this is an unbound value, so I guess this is an old operator that has been removed since, but I can’t find the replacement for it.

Any idea?

P.S.: If you know of any “beginner-friendly” resources about Lwt (or concurrent programming in general), feel free to tell me about them, because it is a tough beast to tame.

1 Like

Heya,

The >> operator is equivalent to >>= fun () ->, i.e.: foo >> bar is foo >>= fun () -> bar. The >> operator is deprecated.

Regarding beginner resources, there is the Mirage Lwt tutorial. Perhaps others can post more nice links. Note that the Mirage tutorial refers to Lwt.ts as threads, even though they are promises (it does point that out in the beginning, though). That is a fault of terminology that we are currently correcting throughout the Lwt docs. We are also writing new ones.

It’s a current priority to create nicer beginner resources. Also, I’ll be adding a link to the Mirage tutorial from the Lwt README shortly. Thanks for prodding me by asking this question :slight_smile:

1 Like

You may also be interested in reading the Real World OCaml chapter on concurrent programming together with @dkim’s nice translation of the examples to Lwt.

Great, thanks a lot. >> is the kind of things that are hard to look up on Google. :wink:

I’ve read Real World OCaml, but having the Lwt examples is great. I’ll also give a look at the Mirage tutorial, it looks promising. I’ll keep an eye out for any new material. :slight_smile:

1 Like

The slightly bad news is that we consider >> to be deprecated these days, since it is part of the camlp4 syntax extension to Lwt.

Most uses of it in our code are replaced by >>= fun () -> or similar uses. In general, there has not been much adoption of the PPX lwt extension in Mirage code since we retired the use of camlp4, and developers seem to prefer just explicitly using the standard Lwt.Infix operators.

2 Likes

There is also this simple server example and walkthrough (code) by @dmbaturin. It looks to be Camlp4-free.

I still haven’t abandoned the idea to write a more structured and thorough, task-oriented tutorial. Doing it alone is hard though, so I really would like someone to collaborate.

1 Like

Well, I don’t think I can help writing such a document, but I can provide feedback from a beginner standpoint, for what it’s worth.

1 Like

@antron @avsm The manual states that >> is included in the Ppx syntax extension as well as the Camlp4 syntax extension.

https://ocsigen.org/lwt/3.0.0/api/Ppx_lwt#2_Sequence

Is the Ppx extension of Lwt considered to be deprecated, together with the Camlp4 extension?

@dmbaturin I’d love to work with you on that, though I have to do several other tasks in Lwt first (contributor documentation, some big PR reviews). @Richard-Degenne your feedback would be very much appreciated :slight_smile:

@dkim Yes, it’s supported in the PPX, though you can disable it with a flag. I’m under the impression that it’s in the PPX only because it was in Camlp4, though I may be wrong. Perhaps @Drup can say what is the status of >>. If deprecated or discouraged, I/we should update the docs.

My personal opinion is that >> should be avoided.

And, respond to edit, the whole PPX is definitely not deprecated.

1 Like

I was somehow convinced I made that thing disabled by default …

So, yes, >> is mostly here because it was in the camlp4 extension. I’m of the opinion it should never have existed and I should not have ported it to ppx. It causes many issues, like users trying to write let f x = foo >> x or things like that. The fact that it looks like a normal operator doesn’t help.

We could deprecate it and add --sequence, then change the default state, I guess.

1 Like

@Drup mind opening an issue in the repo? Maybe we don’t have to change the default state, but just emit a warning when >> is used, plus amend the docs. We can release that in 3.1.0 (July).

Ah, syntax extensions.

In Async, we use a different PPX called ppx_let that’s designed for monads in general, and could be used for LWT as well if people wanted. In that mode, one could write:

let%bind () = some_other expr in

to get the equivalent of >> . We’ve toyed with the idea of supporting a monadic semi, like this:

some_other expr ;%bind

I’m pretty torn as to whether this particular oddity is a good idea, but I do quite like the remainder of the ppx_let. ppx_let also supports match%bind and if%bind, as well as parallel binds (let%bind x = ... and y = ...), as well as %map equivalents. These are especially useful when using an applicative, or a monad where the applicative part is especially important, like Incremental.

2 Likes

For the sake of completeness and clarity in this context, in case one doesn’t follow the link given by @dkim above, and somehow assumes that the PPX provides only >>:

Lwt’s PPX, while having a deprecated >>, supports:

let%lwt () = expr in ...   (* Recommended PPX alternative to >> *)
let%lwt x = expr and y = expr' in ...   (* Parallel composition *)
match%lwt expr with ...
if%lwt expr ...
try%lwt expr with ... [%finally ...]
assert%lwt expr
for%lwt expr do ... done
while%lwt expr do ... done

It’s not as general as ppx_let – it’s only useful for Lwt. Perhaps looking into ppx_let should be some kind of future Lwt project (but I also guess we won’t have the personpower to do it soon).

The Lwt PPX also doesn’t have anything corresponding to let%map. It does have a proposal to add ;%lwt as a replacement for >>:

https://github.com/ocsigen/lwt/pull/307