On Mon, Sep 14, 2020 at 9:38 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

By the original matcher, I mean the matcher that has been extensively
detailed by Wright in his paper. In the original version of this SRFI
you just stuck to its clear semantics: The pattern variables are bound
around the body. (In later versions, the semantics became muddled when
you wrote that pattern variables are also referencable in ? and =
patterns. --- If something like this was already in the first draft, I
must have overlooked it.)

As for how a <decl> clause could look like (copying parts of your example):

(define (cross-peephole vec-product)
(match vec-product
((: a posn-equal?) ('cross a a)) (make-posn 0 0))
((: a slope-equal?) ('cross a a) (make-posn 0 0))
(other other)))

The exact syntax is, of course, debatable. :)

Well, I was thinking the syntax I had, along with these two forms:

(define (make-getter get-f)

(lambda (ref)

(lambda (obj)

(lambda () (get-f obj ref)))))

(define (make-setter set-f)

(lambda (ref)

(lambda (obj)

(lambda (value) (set-f obj ref value)))))

used like:

(import (srfi 69))

(define get-key

(make-getter

(lambda (obj ref) (hash-table-ref/default obj ref #f))))

(define set-key

(make-setter hash-table-set!))

(define ht (make-hash-table))

(define get-mode (match ht ((= (get-key 'mode) g) g)))

(define set-mode! (match ht ((= (set-key 'mode) s) s)))

(get-mode) => #f

(set-mode! 'read)

(get-mode) => read

If pattern variables are not bound early / if an implementation of the srfi makes the choice not to allow repetition in predicates/fields, then an alternate predicate could still be used with failure like:

(define (cross-peephole vec-product)

(match vec-product
(('cross a b) (=> fail)

(if ((posn-equal? a) b) (make-posn 0 0) (fail))
(('cross a b) (=> fail)

(if ((slope-equal? a) b) (make-posn 0 0) (fail))
(other other)))

(or I could redefine with case-lambda if that is portable). I know this is not exactly what you are looking for; I think these procedures provide a straightforward way to work with structures that aren't equal?, or need special get! and set! methods, and if they are part of the spec, to upgrade current matchers to meet the spec. I realize this is not everything anyone could possibly want to do to extend a pattern matcher, but I do think it covers the special equality and record cases. If new (: ...) (var ...) + hygienic record syntax was added, I'm not sure when I would have a sample implementation, and how long testing/benchmarking would take.

Felix