From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: The r6rs record-type in pattern matching of Guile-3.0 Date: Tue, 15 Sep 2020 20:15:27 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f0d82b05af591bd5" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17564"; mail-complaints-to="usenet@ciao.gmane.io" To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Sep 15 14:55:14 2020 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kIAUM-0004UC-7R for guile-devel@m.gmane-mx.org; Tue, 15 Sep 2020 14:55:14 +0200 Original-Received: from localhost ([::1]:49314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kIAUL-00013N-9v for guile-devel@m.gmane-mx.org; Tue, 15 Sep 2020 08:55:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kI9s8-0002oW-F5 for guile-devel@gnu.org; Tue, 15 Sep 2020 08:15:44 -0400 Original-Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]:43347) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kI9s6-0008VS-8Q for guile-devel@gnu.org; Tue, 15 Sep 2020 08:15:44 -0400 Original-Received: by mail-lf1-x12f.google.com with SMTP id y2so2812266lfy.10 for ; Tue, 15 Sep 2020 05:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0EiPr47x53tahpOSOIcqFvdoD0qNjWfqu3h0T/UFr2s=; b=gW7YPJfXYEZ6kYtshPjpgWlvL+sMRNfrXJTFRoy12UIiG2GxfEtPuP7u1TsPOt0tR5 PMEFUwBWmhxGNTebn8H79GQ+6r+UOQqKfTvAWFe4dukGmTbGTH1bTGucV2TVIPhXE8jD Qy8nIoUMkDuMdMT+u4bFU20XL1BYEzJQ0qwH3ErO7lGqON7dXKzIJ6ibmfRAVZQfS9Ug x8QX2sIFySNxlQmT01UN4HqP5RO9dBh6ECEY6fNQEh3HMPnnz9MTfJccxFgoCwrDEY7f uTQAm3Y05/1nSkKbAZQfFxSFUJYEUYH/PI4/iWBAd1U2B3tqlYuo6b8YSpyptCU/0ilO pB8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0EiPr47x53tahpOSOIcqFvdoD0qNjWfqu3h0T/UFr2s=; b=dhRShnYp46UsaHAow1tt+2V3sVTnzIV4bqWqH/srGtqIlQ4D+xm9B034OcsuMnB1Gl 4AakLQCpzjouBozTTQABhAA9AaUTDWyRFUYvD2w8QIinfiUKpbFLjTN2RkgIsiNZbdQH N7FeM+JeQZ5qMtCHn2fy1J5lqcZ1bkQdLYgVEV8NPAM2pY+hXmo0An+KS3OePzCIoQcj FKM6xYYJ1V8iaL5vQLcflYXvnZ9dDkMPDMCitYGDDl5o7Jp7R+pSO95Ud0KlJXbI1Kbn 5ZexcnrFYh/4hteE46ldbbFc+xEx9BYaA4etGuErkhc61WUOUAFFS6ruCydnu2GGLAn6 +wWg== X-Gm-Message-State: AOAM530vSN17yi7SJwPBqY4i7jIqOSEXEUiDtIhmJFJ1NzoYktqkd8N8 I+ZuEbGgsbtw7yQa0XM8WOK9YFkozGpykSIzfl0v3CmMnSbWjg== X-Google-Smtp-Source: ABdhPJwM90M+Yj7rbsQXbdiUaE9DdfuEth4ePnXmRGF7/vqS+PyRBFjL8C9fz+cdODuCrEG+6sjgUzIJlq+92PGg+0I= X-Received: by 2002:a05:6512:2107:: with SMTP id q7mr7041286lfr.63.1600172139270; Tue, 15 Sep 2020 05:15:39 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::12f; envelope-from=nalaginrut@gmail.com; helo=mail-lf1-x12f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:20586 Archived-At: --000000000000f0d82b05af591bd5 Content-Type: text/plain; charset="UTF-8" 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. > > --000000000000f0d82b05af591bd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To whom may care this issue.
According = to the discussion in IRC, here's the memo for the issue, in case anybod= y encounter the same issue again:

The record is no= t nested inherited anymore, this would be the permanent change.
<= div>The good thing is better performance to access record-type, the bad thi= ng is the incompatibility.
If anyone use pattern-matching for par= sing parent of a record-type, then it'll break.

There are probably two workarounds to keep your current code if you use p= attern-matching for parsing parent.
1. Copy and maintain the = old record code:
=C2=A0(rnrs records procedural) and (rnrs record= s 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 a= ssumed first field.

From 3.0, you can't bind t= he parent of record type in the same matching case, the parent (super class= ) would be is-A relationship,
not the previous has-A relationshi= p, so that the parent (super class) is not nested in the record-type anymor= e. The inherited fields
are the parts of the record-type (su= bclass) 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.co= m> wrote:
Hi folks!
I found the r6rs record pattern = matching has different results compared to Guile-2.
Here is the e= xample code:

-------------------------------------= ----code--------------------------------------
,use (rnrs)
,us= e (ice-9 match)

(define-record-type aaa (fields a)= )
(define-record-type bbb (parent aaa) (fields b))
(define r (make-bb= b 1 2))

(match r
=C2=A0 (($ bbb ($ aaa _ a)= b) (list a b))
=C2=A0 (else "no"))
;; =3D=3D= > "no"=C2=A0 in Guile-3
;; =3D=3D=3D> (1 2) in Gu= ile-2

(match r
=C2=A0 (($ bbb a b) (li= st a b))
=C2=A0 (else "no"))
=3D=3D> (1 2)= =C2=A0 in Guile-3
=3D=3D> (<aaa> 2) in Guile-2
=
--------------------------------------------end-----------------------= -----------------------

In Guile-2, we have to spe= cify the parent record-type for binding the fields of the parent, but it se= ems not in Guile-3.0.
I know Guile-3 had tweaked record-type to u= nify the low-level implementation.

My question: Is= this the new expected activity? Do we have to tweak all record type matchi= ng since Guile-3 ?
Or maybe it's just a bug?

Best regards.

--000000000000f0d82b05af591bd5--