A heads-up for an incompatible fix in util.match
TL;DR: If you match records with inheritance using
struct match pattern, you need to change the code for 0.9.6.
We fixed a bug in the positional record matching pattern of
match, existed in 0.9.5 and before.
The fix actually breaks previously documented behavior, but
we believe the previous behavior was incorrect and decided it's better
to fix now.
struct pattern allows you to extract slot values
from objects using
(define-class <point> () ((x :init-keyword :x) (y :init-keyword :y) (z :init-keyword :z))) (match (make <point> :x 1 :y 2 :z 3) [($ <point> a b c) (list a b c)]) => (1 2 3)
However, Gauche's object system isn't designed to access slots
with their positions. You use slot names instead. In
you can use
object pattern (or
@ in sort) to match
with slot values, using slot names.
(match (make <point> :x 1 :y 2 :z 3) [(@ <point> (x a) (y b) (z c)) (list a b c)]) => (1 2 3)
The reason we provided
$ was for the compatibility of
match, which aimed at
provided in some Scheme impelementations. We didn't give much
thought to it; just made the pattern match with the slot values
of the order of
It works just fine with srfi:9 records:
(define-record-type pare (make-pare fst snd) pare? (fst get-fst) (snd get-snd)) (match (make-pare 1 2) [($ pare a b) (list a b)]) => (1 2)
Things got complicated when inheritance enters the picture.
How the inherited slots are laid out depends on the implementation
of metaclass (ref:compute-slots generic function),
and because of multiple inheritance,
the slot layout of class S doesn't necessarily a subsequence
of the layout of class T that inheriting S. This is highly confusing,
and we've always recommended
object match in such a case, in the manual.
However, srfi:99 records only allows single inheritance chain, and the default constructor takes initial value of inherited slot first. So it is a natural call to make positional match in the same way.
(define-record-type S make-S S? a b) (define-record-type (T S) make-T T? ;; inherit S c d) (make-S 1 2) ;; Initialize a=1, b=2 (make-T 1 2 3 4) ;; Initialize a=1, b=2, c=3, d=4 ;; Then, ($ T w x y z) should match with w=1, x=2, y=3, z=4.
It hadn't been so. The
compute-slots method of
placed the direct slots first, followed by the inherited slots.
It needs to do so to be consistent with that "fields in derived
record types shadow fields of the same name in a parent record type",
as defined in srfi-99.
($ T w x y z) pattern in the above example
matched w=3, x=4, y=1, and z=2.
This wasn't inconsistent with the manual, which stated
that positional match was done with the order of
It was an unintended artifact of implementation that was overlooked,
It also had a defect when duplicate slot names existed.
When a subclass defines a slot with the same name as inherited slot,
compute-slots merges them into one, which is also
CLOS's behaviro. However, srfi:99 record types allow subtype
to have slots with the same name but as independent slots.
(define-record-type S #t #t a) (define-record-type (T S) #t #t a) (define t (make-T 1 2)) (T-a t) ;=> 2 ; accesses T's a (S-a t) ;=> 1 ; accesses S's a in T (slot-ref t 'a) ;=> 2 ; named access takes the subtype's slot
The existing implementation of positional matching needed to rely on named slot access, and didn't work on such record types.
We introduced a generic function to be specialized with metaclass,
that handles positional access within
match. We keep the
underlying mechanism undocumented
for now; changing the way of positional matching should be rare
and based on well-established customs. The order of record types
fits this criteria, and made to work as expected:
(define-record-type S make-S S? a b) (define-record-type (T S) make-T T? ;; inherit S c d) (match (make-T 1 2 3 4) [($ T w x y z) (list w x y z)]) => (1 2 3 4)
Now it also works with record types having duplicate slot names:
(define-record-type S #t #t a) (define-record-type (T S) #t #t a) (match (make-T 1 2) [($ T x y) (list x y)]) ;=> (1 2); was (2 2) before
We hope few have used positional match with inherited records--- the old behavior seems apparently wrong---so we decided to fix this now.
If you happen to have the code that relies on the previous behavior,
and need to make it work with both versions, you can switch to use
named match (