[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile foreign object interface
From: |
Ludovic Courtès |
Subject: |
Re: Guile foreign object interface |
Date: |
Tue, 07 Mar 2017 21:02:53 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Howdy!
Andy Wingo <address@hidden> skribis:
> On Tue 07 Mar 2017 14:44, address@hidden (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’.