Daphne,

On 2025-11-05 21:04 +0100, Daphne Preston-Kendal wrote:
> > Pattern-matching is timeless, at least conceptually, but iteration
> > is, well, iterative, happening through time.
>
> I don’t understand this objection; based on what follows I think it’s
> rooted in a misunderstanding.

I think I now understand what 'seq' does, although I'm not sure
whether it's the best way to express what it does, or whether it
should be split into different patterns for differently-structured
sequence types.  I did misunderstand the way it binds unellipsized
sequence patterns, but you've cleared that up.

Part of the problem is that, in feeling my way toward the source
of the vague worry I have about 'seq' and friends, I wasn't able to
express that worry very well.  After playing around with 'seq' a bit,
I think I know what bothers me, & I will try (again) to articulate it.
Since I can't come up with anything better at the moment, feel free
to skip the following.

What bothers me, as I tried to express, is the mix of declarative
(pattern-matching) & procedural (loop) idiom.  If I've understood
correctly, 'seq' uses a description of an iterative process to construct
an abstract sequence whose elements are matched against the <sequence
pattern>s.  This avoids reifying new sequence types as old sequence
types, which is a win for extending the matcher efficiently.

But there are several ways to describe an abstract sequence.
SRFI 257's analogous '~iterate' pattern uses something like an
unfold.  The Haskell literature is full of ways to use coalgebras and
fixpoints to describe the construction of inductively-defined types.
(I would need Marc's help to make sense of much of that.)  In more
down-to-earth terms, we have indexed sequence types like vectors &
inductively-defined sequences like lists; is it a good idea to use
the same 'do'-like description for both varieties?  (I don't know.)

While the current design works, there may be equivalent (?) but more
expressive ways to define a sequence matcher, perhaps specialized 'seq'
patterns for indexed and inductively-defined types.  It may also be
possible to simplify & clarify the 'seq' specification.  I'll keep
playing around with it.

***

An unrelated point: I think SRFI 262's pattern language is a very nice
set of forms.  It is much cleaner than the Wright or Shinn languages.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>