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 <nalagin...@gmail.com> 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 > ==> (<aaa> 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. > >