Seq.t and persistence

What exactly is your concern with Seq.cons in this case? Note that Seq.t is just an alias for a unit-arg function which itself returns the inner node type. So as the implementor of a Seq.t, you get to choose exactly what is evaluated and when’d. More concretely, e2 in your example would be a function that returns the tail sequence when passed to a Cons value constructor. I’m not sure exactly what the implications would be of double-memoizing, but you can always create your own memoized list by wrapping the value in a Lazy.t.

You may find this thread interesting. In particular, the pattern recommended by @silene. This appears to be a robust construction in my testing and it also allows you to use combinators efficiently on top of the underlying “manual” sequences as long as you’re doing O(1) work per combinator operation. In other words, you don’t need to repeatedly call Seq.memoize (and in fact likely don’t want to use that anywhere).