unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: John Cowan <cowan@ccil.org>
To: Christopher Lam <christopher.lck@gmail.com>
Cc: guile-user <guile-user@gnu.org>
Subject: Re: srfi-9 vs make-record-type
Date: Sun, 21 Jul 2019 15:21:14 -0400	[thread overview]
Message-ID: <CAD2gp_TuFq=d7X7gEjxGHraMW9JdhbLaDC+svat7jkzuSVL+tw@mail.gmail.com> (raw)
In-Reply-To: <CAKVAZZKUKEJZtQiEZemDSN17S1_D0U_pe_=DdeiL4C9Ve8vpSg@mail.gmail.com>

On Sun, Jul 21, 2019 at 6:21 AM Christopher Lam <christopher.lck@gmail.com>
wrote

In experiments converting legacy code to use srfi-9 records, I'm finding
> the latter doesn't travel well across modules.
>

In SRFI 9 you need to define a record type in exactly one module and then
export whatever subset of the constructor, predicate, accessors, and
mutators (not typically the record type name) that you want to make
visible.  Other modules can then import those names.  This is because calls
on define-record-type are generative (SRFI 9 doesn't say so, but in
practice they are), so a particular record type should be defined only once.

In my code, I often export the predicate and accessors, but not the
constructor or mutators.  Then I export a factory method that may or may
not call the constructor.

It may be convenient to define the record-type in its own module.


John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Promises become binding when there is a meeting of the minds and
consideration
is exchanged. So it was at King's Bench in common law England; so it was
under the common law in the American colonies; so it was through more than
two centuries of jurisprudence in this country; and so it is today.
       --Specht v. Netscape


  reply	other threads:[~2019-07-21 19:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-21 10:20 srfi-9 vs make-record-type Christopher Lam
2019-07-21 19:21 ` John Cowan [this message]
2019-08-05 18:18 ` Mark H Weaver
2019-08-26 12:20   ` Christopher Lam
2020-07-13 13:07     ` Christopher Lam

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='CAD2gp_TuFq=d7X7gEjxGHraMW9JdhbLaDC+svat7jkzuSVL+tw@mail.gmail.com' \
    --to=cowan@ccil.org \
    --cc=christopher.lck@gmail.com \
    --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).