From: ludo@gnu.org (Ludovic Courtès)
To: Andy Wingo <wingo@pobox.com>
Cc: guile-user@gnu.org, guile-devel@gnu.org
Subject: Re: Guile foreign object interface
Date: Tue, 07 Mar 2017 21:02:53 +0100 [thread overview]
Message-ID: <877f40svma.fsf@gnu.org> (raw)
In-Reply-To: <87r32988we.fsf@pobox.com> (Andy Wingo's message of "Tue, 07 Mar 2017 15:21:37 +0100")
Howdy!
Andy Wingo <wingo@pobox.com> skribis:
> On Tue 07 Mar 2017 14:44, ludo@gnu.org (Ludovic Courtès) writes:
>
>> I think Mark made two kinds of comments back then:
>>
>> 1. There were suggestions about the API itself, nothing deep:
>> <https://lists.gnu.org/archive/html/guile-devel/2014-04/msg00070.html>.
>> Andy, do you know if they’ve been addressed?
>
> There were a couple points I think:
>
> In
>
> SCM scm_make_foreign_object_type (SCM name, SCM slot_names,
> scm_t_struct_finalize finalizer);
>
> Mark suggested it should be "scm_t_struct_finalizer". I.e. with an r.
> I can agree but scm_t_struct_finalize is a type that's already in 2.0;
> it's just being re-used here. That said we can do the new name +
> typedef + eventually deprecate the old name dance.
Good point; given the type is already there in 2.0, I’d be in favor of
keeping it as is (without the ‘r’).
> He also suggested to get rid of some type punning, and indeed now we
> have:
Perfect.
>> 2. A general concern about “API churn” and our ability to support the
>> SMOB API in the future, which I can sympathize with:
>> <https://lists.gnu.org/archive/html/guile-devel/2015-11/msg00005.html>.
>>
>> Essentially, (1) it should be easy for people to migrate from SMOBs
>> to foreign objects (I think it’s largely a matter of
>> documentation), and (2) existing code that uses the documented SMOB
>> API should just work in 2.2, possibly with a deprecation warning.
>
> I am not so sure about about this one. I think it's not accurate to
> characterize beginning to replace a 25-year-old C API (SMOBs) as
> "churn".
I think the point is that there’s lots of code out there that rely on
SMOBs and we shouldn’t break it overnight, precisely because that API is
this old.
Of course, I agree that pushing users towards an improved API is the
right thing long term, no argument here.
> I will get to Mark's point specifically in a minute but regarding your
> points I believe that (1) is somewhat under-documented; the
> documentation is more oriented towards new users than migrating users;
> we can improve here; and (2) should work fine (the old API is still
> there, not even any deprecation warnings currently).
Sounds good.
> I think Mark's desire (if I understand it) was for the new API to
> completely replace the old in all forms, specifically in support for
> mark procedures. I really think that (a) we should not support the SMOB
> mark procedure interface, as it's both horrible and insufficient for a
> moving collector, and (b) that until we have a moving collector (?), we
> shouldn't attempt to speculatively standardize anything in this regard.
> Basically the arguments from here:
>
> https://lists.gnu.org/archive/html/guile-devel/2015-11/msg00003.html
>
> There's still the SMOB API if you need mark procedures, basically, but
> hopefully you don't (e.g. when porting GDB to 2.0 I was able to remove
> them; they're less necessary in 2.x than they were in 1.8). Some users
> still need them, which is why SMOBs are still around :)
Understood.
I think we’ve achieved our goal if code that is not ready to migrate
works the same as with 2.0, which should be the case AIUI.
So, green lights for me. :-)
Thank you,
Ludo’.
next prev parent reply other threads:[~2017-03-07 20:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1644439317.409814.1488469678720.ref@mail.yahoo.com>
2017-03-02 15:47 ` Guile foreign object interface Mike Gran
2017-03-06 20:26 ` Andy Wingo
2017-03-06 20:26 ` Andy Wingo
2017-03-07 13:44 ` Ludovic Courtès
2017-03-07 14:21 ` Andy Wingo
2017-03-07 20:02 ` Ludovic Courtès [this message]
2017-03-07 22:31 ` David Kastrup
2017-03-08 20:59 ` Ludovic Courtès
2017-03-08 23:00 ` David Kastrup
2017-03-09 5:49 ` Thien-Thi Nguyen
2017-03-09 21:59 ` David Kastrup
2017-03-09 12:09 ` Ludovic Courtès
2017-03-09 15:47 ` Eli Zaretskii
2017-03-09 17:26 ` Ludovic Courtès
2017-03-09 18:31 ` Eli Zaretskii
2017-03-09 19:56 ` Andy Wingo
2017-03-10 7:38 ` Eli Zaretskii
2017-03-10 8:06 ` Andy Wingo
2017-03-10 8:47 ` David Kastrup
2017-03-10 10:15 ` Arne Babenhauserheide
2017-03-10 10:55 ` David Kastrup
2017-03-11 16:31 ` Arne Babenhauserheide
2017-03-11 17:26 ` David Kastrup
2017-03-11 20:32 ` Arne Babenhauserheide
2017-03-09 22:38 ` David Kastrup
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=877f40svma.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
--cc=guile-user@gnu.org \
--cc=wingo@pobox.com \
/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).