# Seq.t and persistence

**URL:** <https://discuss.ocaml.org/t/seq-t-and-persistence/16213>\
**Category:** Ecosystem\
**Created:** [March 3, 2025, 3:53am UTC](https://discuss.ocaml.org/t/seq-t-and-persistence/16213 "2025-03-03T03:53:52Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![bsidhom](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/bsidhom/32/5763_2.png) [@bsidhom](https://discuss.ocaml.org/u/bsidhom)\
**Post date:** [March 3, 2025, 6:09pm UTC](https://discuss.ocaml.org/t/seq-t-and-persistence/16213/4 "2025-03-03T18:09:26Z")

</div>

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](https://discuss.ocaml.org/t/recommended-patterns-and-techniques-for-seqs-especially-when-memoized/16019/1) interesting. In particular, the [pattern recommended](https://discuss.ocaml.org/t/recommended-patterns-and-techniques-for-seqs-especially-when-memoized/16019/5) 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).

---

_[View the full topic](https://discuss.ocaml.org/t/seq-t-and-persistence/16213)._