Re: Guile foreign object interface

[ludo@gnu.org (Ludovic Courtès)]

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’.