The r6rs record-type in pattern matching of Guile-3.0

The r6rs record-type in pattern matching of Guile-3.0

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1437 bytes --]

Re: The r6rs record-type in pattern matching of Guile-3.0

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]

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 <nalaginrut@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.
>
>

[-- Attachment #2: Type: text/html, Size: 3316 bytes --]