To whom may care this issue. According to the discussion in IRC, here's the memo for the issue, in case anybody encounter the same issue again: The record is not nested inherited anymore, this would be the permanent change. The good thing is better performance to access record-type, the bad thing is the incompatibility. If anyone use pattern-matching for parsing parent of a record-type, then it'll break. There are probably two workarounds to keep your current code if you use pattern-matching for parsing parent. 1. Copy and maintain the old record code: (rnrs records procedural) and (rnrs records syntactic) from 73d0a3bccb3c2b79d7f0e3aaca88a84f3a5c3f43 2. The r6rs record-type is powerful so that you may customize it by redefine its constructor to always put its parent to the first field. So that pattern-matching can correctly parse the parent in its assumed first field. From 3.0, you can't bind the parent of record type in the same matching case, the parent (super class) would be is-A relationship, not the previous has-A relationship, so that the parent (super class) is not nested in the record-type anymore. The inherited fields are the parts of the record-type (subclass) from now on, which would be faster for access, obviously. Best regards. On Tue, Aug 25, 2020 at 4:16 AM Nala Ginrut wrote: > Hi folks! > I found the r6rs record pattern matching has different results compared to > Guile-2. > Here is the example code: > > > -----------------------------------------code-------------------------------------- > ,use (rnrs) > ,use (ice-9 match) > > (define-record-type aaa (fields a)) > (define-record-type bbb (parent aaa) (fields b)) > (define r (make-bbb 1 2)) > > (match r > (($ bbb ($ aaa _ a) b) (list a b)) > (else "no")) > ;; ==> "no" in Guile-3 > ;; ===> (1 2) in Guile-2 > > (match r > (($ bbb a b) (list a b)) > (else "no")) > ==> (1 2) in Guile-3 > ==> ( 2) in Guile-2 > > --------------------------------------------end---------------------------------------------- > > In Guile-2, we have to specify the parent record-type for binding the > fields of the parent, but it seems not in Guile-3.0. > I know Guile-3 had tweaked record-type to unify the low-level > implementation. > > My question: Is this the new expected activity? Do we have to tweak all > record type matching since Guile-3 ? > Or maybe it's just a bug? > > Best regards. > >