unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* The r6rs record-type in pattern matching of Guile-3.0
@ 2020-08-24 20:16 Nala Ginrut
  2020-09-15 12:15 ` Nala Ginrut
  0 siblings, 1 reply; 2+ messages in thread
From: Nala Ginrut @ 2020-08-24 20:16 UTC (permalink / raw)
  To: guile-devel; +Cc: Andy Wingo

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: The r6rs record-type in pattern matching of Guile-3.0
  2020-08-24 20:16 The r6rs record-type in pattern matching of Guile-3.0 Nala Ginrut
@ 2020-09-15 12:15 ` Nala Ginrut
  0 siblings, 0 replies; 2+ messages in thread
From: Nala Ginrut @ 2020-09-15 12:15 UTC (permalink / raw)
  To: guile-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-09-15 12:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-24 20:16 The r6rs record-type in pattern matching of Guile-3.0 Nala Ginrut
2020-09-15 12:15 ` Nala Ginrut

unofficial mirror of guile-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guile-devel/0 guile-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guile-devel guile-devel/ https://yhetil.org/guile-devel \
		guile-devel@gnu.org
	public-inbox-index guile-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.lisp.guile.devel
	nntp://news.gmane.io/gmane.lisp.guile.devel


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git