rudimentary module Lwt_opt (RFD, do not pull!)

[jrochel]

Hello,

This patch is not complete (as it lacks documentation, "girth" and integration into the the _oasis file etc.) and is only meant as a request for discussion.

If I were to write some convenience functions as in this patch from time to time, would they be welcome and possibly be adopted? I also have a few similar addendums in mind for Lwt_list.

[aantron]

It would be nice to have some kind of disciplined rule about/approach to such things.

On the one hand, I also have coded helper functions for dealing with options and Lwt, as I'm sure have many others. And, we also added something similar for result recently.

On the other hand, there is the desire to keep the interface brief. I already have a strong urge to remove things from Lwt :)

One reason for adding Lwt_result was that there was already a result type in Lwt, and we redefined it in terms of the new standard result. I don't think Lwt has this interaction with option.

Would be nice to get opinions – cc @c-cube, @Drup, @hcarty, others?

[c-cube]

Sorry, I really have no opinion ^^. I get by with option combinators and >|=, mostly.

[Drup]

No real opinion either, but I would suspect that such module is much less useful once you use a real stdlib. Result and Lwt have real interactions and the order of evaluation is important for Lists and Lwt.

You could argue we need generic monad transformers, but bleh :p

[hcarty]

I agree with @c-cube and @Drup, though it would feel a little strange to have Lwt_result and not Lwt_opt(ion). After spending more time with modules like this my experience has been that they tend to cause more trouble than "just" doing the option/result/Lwt.t layering by hand.

[aantron]

Ok, then I think Lwt shouldn't add Lwt_opt(ion) at this point, to remain brief. Lwt_option and similar modules may be a good idea for a separate library, however.

What kind of things do you have in mind for Lwt_list? That module already exists, and if it is missing functions that are commonly needed, it may make sense to add those, especially if they are not completely trivial to implement in terms of the existing ones.

Thanks, all :)

[jrochel]

For Lwt_list I have currently only val lwt_sequence : 'a Lwt.t list -> 'a list Lwt.t. I might follow your suggestion and start a separate library sometime (soon?).

Thanks to you all for your feedback.
Closing...