would it be feasible and/or desirable to have a function of the type 'a t list -> 'a list t that produces all possible combinations of elements from the sequences?

having include Seq would be useful to keep remaining a strict extension even as Seq grows. Question is more, where in the file would it go?

• beginning ⇒ still risk of incompatibility because of functions that might be shadowed in a different way
• end ⇒ risk of backward breakages for OSeq as new stdlib functions hide our code

replace qtest/jbuild with branch wip-qtest-dune

we can assume the iterators are pure, and therefore traverse in the normal order

There are 2 questions in total in their individual sections below.

1. Prebuilt number sequences?

I've found myself needing number sequences quite frequently, and reckon it'd be nice if OSeq comes with prebuilt ones.

I'm adding some right now and intended to make it into a PR later, which will include the following sequences

• naturals
• arithmetic
• geometric (positive and integral ratio)
• odd numbers (positive, negative)
• even numbers (positive, negative)
• zero to n (exclusive, inclusive)
• range (exclusive, inclusive)

Q: Do you think prebuilt number sequences is useful and within the scope of OSeq? Or is it a better idea that I create another package just for number sequences?

EDIT: I read the doc again and realised above can be easily implemented using take, cycle, iterate, so maybe they aren't useful as prebuilts, but I'll wait for an answer to confirm anyhow.

2. Use of ocamlformat and cinaps?

If the answer to Q1 is positive (i.e. you'll accept the PR), then do you accept use of cinaps (and consequently ocamlformat) for the project?

I intend to have both int64 and int versions for the above sequences, and reckon using Cinaps for code generation would minimise human errors and code copy+pasting. As a direct result, ocamlformat is needed to make sure committed code is readable.

I am guessing ocamlformat is not used in OSeq purely because I don't seem to see ocamlformat used in the Makefile, which may be way off.

take_while has the following entry in oseq.mli:

val take_while : ('a -> bool) -> 'a t -> 'a t
(** Take elements while they satisfy the predicate. The initial iterator
    itself is not to be used anymore after this. *)

The comment about using the initial iterator doesn't seem like it's always appropriate since a seq value is not drained* by traversal. Is this a leftover doc comment from the sequence/iter library?

[*] With the caveat that an underlying source like a file or socket may have its contents drained during traversal

The odoc CSS is not applying on the API docs: https://c-cube.github.io/oseq/oseq/OSeq/index.html

This is due to a teeny-tiny behaviour change in odoc which GitHub Pages doesn't like--they started using a directory called _odoc_support to contain all the support files (including CSS), and GitHub Pages by default ignores any directories starting with _.

Can be fixed easily by just adding an empty file called .nojekyll in the root directory in the gh-pages branch.

Hi,

If I understand the documentation correctly, OSeq.merge is supposed to perform “dovetailing”, i.e. the resulting sequence should contain all the elements of the input sequences. This does not seem to work for infinite sequences, though.

For example if the input sequences are

(0,0), (0,1), (0,2), …
(1,0), (1,1), (1,2), …
(2,0), (2,1), (2,2), …
….

Then merge returns

(0,0), (1,0), (2,0), (3,0) , …

But I would expect the merge to look like

(0,0),(1,0),(0,1),(2,0),(1,1),(0,2),(3,0),(2,1),(1,2),(0,3),(4,0),(3,1),(2,2),(1,3),(0,4),…

If you agree, then I think line 657/658 in OSeq should be replaced by:

| Cons (g, tl') ->
  let q = F_queue.push g q in
  let g', q = F_queue.pop_exn q in
  yield_from g' q tl'

Then it would roughly give the above sequence (up to local permutations). I also have some code to give exactly the sequence above if you’d prefer that.