Add useful functions to Seq module

[yawaramin]

Would some contributions be welcome into the Seq module? Does anyone already have some functions implemented? I found a couple waiting for review in #9077, and I have a few more implemented on my machine:

• range
• fold_right (not tailrec)
• take_while (short-circuiting)
• take (n)
• exists (predicate)

[damiendoligez]

Ping @c-cube @alainfrisch @fpottier. Opinions on the idea of including these functions?

[c-cube]

Sure, it'd be useful. I have doubts about fold_right, it's not efficient to implement and of dubious utility imho. The other ones should be there.

Pretty sure all of these (except fold_right) are in oseq already, and I agree with merging them upstream.

[yallop]

I think it would be good to favour functions which work with infinite streams, so far as possible. (I think fold_left is currently the only exception). So:
+1 to range, take_while, take
-0 to exists (which returns true or false for a finite stream, but returns true or fails to terminate for an infinite stream).

[fpottier]

As a general comment, the current Seq offers way too few functions; many natural functions are missing.

I didn't know about oseq, but it seems to offer a lot of functionality.

I also have a Sequel module in the works, which contains many functions.

I think it would be good to move the more "canonical" functions to Seq, and to keep the more "exotic" functions in a third-party library like oseq. I would be happy to contribute some code from Sequel to oseq, if @c-cube agrees.

[nojb]

I think it would be good to favour functions which work with infinite streams, so far as possible. (I think fold_left is currently the only exception).

While I sympathize with this opinion, I think that following it would run counter to the idea behind Seq, which is to be a kind of "lingua franca" of containers (at least that's how I understood it). It would mean that to do something as simple as exists or for_all we would be forced to convert the seq to a list, which seems overly bureocratic (not to mention inefficient). I would rather include both kinds of functions, and clearly indicate which ones do not apply to infinite sequences.

Regarding the issue at hand, I think it would be great to have the widest possible selection of general function in Seq; something like the union of @fpottier's Sequel and @c-cube's oseq, minus those that are overly specific or exotic.

[c-cube]

I would be happy to contribute some code from Sequel to oseq, if @c-cube agrees.

@fpottier that'd be very nice, thank you. Note that oseq is BSD2 though :). In any case I'm ok with any subset of oseq to be ported to the stdlib and become LGPL there.

[fpottier]

I don't mind the license. Maybe we should get together at some point (in August?) and propose a set of additions to Seq taken from oseq and Sequel.

[github-actions]

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

[yawaramin]

I think an agreement was reached to upstream some set of functions from oseq/Sequel into Stdlib.Seq. I am happy to drive this forward a bit more. I will set up a PR if no objections.

[gasche]

No objections.

@c-cube and @fpottier: August is coming again!

[c-cube]

I'm available to talk in august after the 9th, if @fpottier is also willing :)

[fpottier]

Also available from August 9 and on. @c-cube, please email me and we can set a date and time. @gasche, would you like to participate in the discussion?

[c-cube]

By writing that comment, @gasche has already agreed to participate in the discussion, under perjury. :).
I'll email y'all.

[jhwoodyatt]

I have written a whole passle of additional functions for the Seq.t type in my Orsetto project. You can see them here. (It's BSD2, and I'm okay with OCaml snarfing anything you guys think is useful.)

[gasche]

The joint work of @c-cube and @fpottier was merged in 4.14 as #10583. Of course we can think of many more functions to add to the module, and I sure hope people will come with good suggestions in the future, but I think we can give ourselves (and in particular @yawaramin) a pat in the back for the largest feature addition in the stdlib we have seen in a while, a close the present issue for now.

[yawaramin]

And the amazing thing is I ended up doing literally nothing! Fantastic work, thanks all.