unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Taylan Kammer <taylan.kammer@gmail.com>
To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
Cc: guile-user@gnu.org
Subject: Re: Guix records
Date: Wed, 10 Feb 2021 06:37:32 +0100	[thread overview]
Message-ID: <2c723161-6be9-26e0-dfc0-14e43cdda6fc@gmail.com> (raw)
In-Reply-To: <87o8gs68gw.fsf@web.de>

On 10.02.2021 02:02, Dr. Arne Babenhauserheide wrote:
> 
> Taylan Kammer <taylan.kammer@gmail.com> writes:
>> The most feature-rich record system supported by Guile is probably the
>> R6RS record system, which is available through the modules:
>>
>>    (rnrs records syntactic (6))
>>    (rnrs records procedural (6))
>>    (rnrs records inspection (6))
>> Here's a super brief example usage of R6RS records, demonstrating that
>> field accessors are defined implicitly, but constructors still use an
>> unnamed sequence of arguments to assign fields:
>>
>>    (import (rnrs records syntactic (6)))  ; must use 'import' for R6RS
>>
>>    (define-record-type (cat make-cat cat?) (fields name age color))
>>
>>    (define garfield (make-cat "Garfield" 42 'orange))
>>
>>    (cat-color garfield)  ;=>  orange
> 
> I did not know about that shorthand — thank you!
> 
> I always did this:
> 
> (import (srfi srfi-9)) ; define-record-type
> (define-record-type <cat>
>    (make-cat name age color)
>    cat?
>    (name cat-name) (age cat-age) (color cat-color))
> 
> Compared to that the syntactic form you showed is much nicer.

I actually prefer the conceptual simplicity and explicit nature of 
SRFI-9 to be honest, but yeah, it can be very verbose.

> Is there a difference in efficiency or such?

Theoretically there shouldn't be, since the implicit defining of the 
accessors happens at compile time.  However, pre Guile 3.0, the R6RS 
record system was implemented completely independently from the SRFI-9 
implementation, so the two could have various differences in performance.

According to the 3.0 release notes, R6RS and SRFI-9 now both use a 
unified core record system under the hood and should therefore have 
equivalent performance characteristics I suppose.

> Best wishes,
> Arne
> 

- Taylan



  reply	other threads:[~2021-02-10  5:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-05 16:51 Guix records Olivier Dion via General Guile related discussions
2021-02-09 23:14 ` Taylan Kammer
2021-02-10  1:02   ` Dr. Arne Babenhauserheide
2021-02-10  5:37     ` Taylan Kammer [this message]
2021-02-10  8:38       ` Dr. Arne Babenhauserheide
2021-02-09 23:32 ` Aleix Conchillo Flaqué
2021-02-10  0:28   ` Olivier Dion via General Guile related discussions
2021-02-10 21:11     ` Aleix Conchillo Flaqué
2021-02-26 17:36 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c723161-6be9-26e0-dfc0-14e43cdda6fc@gmail.com \
    --to=taylan.kammer@gmail.com \
    --cc=arne_bab@web.de \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).