unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Christopher Lam <christopher.lck@gmail.com>
Cc: guile-user <guile-user@gnu.org>
Subject: Re: srfi-9 vs make-record-type
Date: Mon, 13 Jul 2020 13:07:23 +0000	[thread overview]
Message-ID: <CAKVAZZJR=n9SaPFf=D=TiWhb_d6+9b3b+evXuQiFCfbqw138Pg@mail.gmail.com> (raw)
In-Reply-To: <CAKVAZZ+Zs2r_EZ7shzyW5Y4M4zieRCde8+HcgUXyccPudbxjmA@mail.gmail.com>

Followup.
As part of preparation for compatibility with guile-3, we've changed
gnucash's use of make-record-type to define-record-type.
Since the record field getters and setters are not exportable across
modules, we've used the following forms.

(define-record-type :record
 (make-record field1 field2)
 record?
 (field1 field1-getter field1-setter)
 (field2 field2-getter field2-setter))
(define-public gnc:field1-getter field1-getter)
(define-public gnc:field1-setter field1-setter)
(define-public gnc:field2-getter field2-getter)
(define-public gnc:field2-setter field2-setter)

There may be a more elegant solution but for now it'll do. See the set of
related commits at
https://github.com/Gnucash/gnucash/commits?after=00bbd32677fba00ae0e709dce0bb35e06f90305c+4
onwards.

On Mon, 26 Aug 2019 at 12:20, Christopher Lam <christopher.lck@gmail.com>
wrote:

> Thank you Mark and John.
>
> On Mon, 5 Aug 2019 at 18:18, Mark H Weaver <mhw@netris.org> wrote:
>
>> The problem here is that 'make-person' is a macro.  Macros are expanded
>> at compile time, and must therefore be available at compile time.
>>
>> When you compile 'm2.scm', those macros are not available, because
>> 'load' only has effects at run-time, by design.  Since there is no macro
>> definition for 'make-person' at compile-time, Guile's compiler generates
>> code that assumes it will be a procedure.
>>
>> In summary, you cannot use 'load' to import macros from another module.
>>
>> > For various reasons I must keep (load "module.scm") mechanism
>> If you can share those reasons, perhaps I can help you find another
>> solution.
>>
>
> The only reason is that I've started cleaning up numerous modules in
> GnuCash written about 20 years ago, and the hyper-modular approach is too
> difficult to try unravel for now. So, I've converted records to srfi-9
> wherever possible (i.e. used internally), and left the exported ones alone.
> This one was a fun one to fix:
> https://github.com/Gnucash/gnucash/commit/e3a695d0 ;-)
>


      reply	other threads:[~2020-07-13 13:07 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
2019-08-05 18:18 ` Mark H Weaver
2019-08-26 12:20   ` Christopher Lam
2020-07-13 13:07     ` Christopher Lam [this message]

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='CAKVAZZJR=n9SaPFf=D=TiWhb_d6+9b3b+evXuQiFCfbqw138Pg@mail.gmail.com' \
    --to=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).