Complexity of seq & related patterns Wolfgang Corcoran-Mathe (05 Nov 2025 19:37 UTC)
Re: Complexity of seq & related patterns Daphne Preston-Kendal (05 Nov 2025 20:05 UTC)
Re: Complexity of seq & related patterns Daphne Preston-Kendal (06 Nov 2025 20:07 UTC)
Re: Complexity of seq & related patterns Wolfgang Corcoran-Mathe (07 Nov 2025 18:22 UTC)
Re: Complexity of seq & related patterns Daphne Preston-Kendal (25 Nov 2025 10:37 UTC)
Re: Complexity of seq & related patterns Wolfgang Corcoran-Mathe (07 Jan 2026 22:49 UTC)

Re: Complexity of seq & related patterns Daphne Preston-Kendal 06 Nov 2025 20:07 UTC

On 5 Nov 2025, at 21:04, Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:

>> So much for the curiousities of 'seq'. 'seq*' is curiouser still, &
>> as for 'seq/unordered', or 'seq/reorderable', or 'seq/interleaving'
>> ... the naming difficulties give some idea of the semantic monsters
>> dwelling there.
>
> seq* is indeed not very satisfactory. It’s there to enable the ‘cons*’ pattern and things like it.
[snip]
> In general, a pattern (my-spiffy-sequence-type <<subpatterns>>) should expand into (seq <<the state vars etc for a my-spiffy-sequence-type>> <<subpatterns>>) – exactly replicating the subpatterns and just telling the matcher how to iterate over the sequence. One of the infelicities of seq* is that this is currently not the case.

To remedy this problem of seq* I have created a version which uses two <<ref expression>>s instead of one. The first ref expression is for all the patterns except the final (tail-matching) one, the second ref expression is for the final pattern.

It’s on a branch of the sample implementation for now: <https://codeberg.org/dpk/extensible-match/src/branch/double-ref-seqstar>.

Excluding a performance cheat used in the real implementation (which I also hope to get rid of some day), the implementation of cons* changes from the rather unwieldy:

(define-pattern-syntax cons*
  (lambda (stx)
    (syntax-case stx ()
      ((_ pat-or-ell ... rest-pat)
       #`(seq* ls ((more ls (cdr more)))
               (not (pair? more))
               more
           #,@(map
               (lambda (pat-or-ell)
                 (if (match-ellipsis? pat-or-ell)
                     pat-or-ell
                     #`(=> car #,pat-or-ell)))
               #'(pat-or-ell ...))
           rest-pat)))))

to the much simpler:

(define-pattern-syntax cons*
  (syntax-rules ()
    ((_ pat ... rest-pat)
     (seq* ls ((more ls (cdr more)))
           (not (pair? more))
           (car more)
           more
       pat ... rest-pat))))

This is not really a solution to the problem of the seq patterns being complex. It shuffles complexity around more than it than reduces or eliminates it.

However, this does get rid of the one major use case for match-ellipsis?, which is also an ugly hack I’m tempted to get rid of if I do merge this branch.

Daphne