Re: Guile foreign object interface

[Andy Wingo]

Hi :)

Thanks for taking the time to look at the issue!

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.

He also suggested to get rid of some type punning, and indeed now we
have:

  void* scm_foreign_object_ref (SCM obj, size_t n);
  void scm_foreign_object_set_x (SCM obj, size_t n, void *val);

  scm_t_bits scm_foreign_object_unsigned_ref (SCM obj, size_t n);
  void scm_foreign_object_unsigned_set_x (SCM obj, size_t n,
                                          scm_t_bits val);

  scm_t_signed_bits scm_foreign_object_signed_ref (SCM obj, size_t n);
  void scm_foreign_object_signed_set_x (SCM obj, size_t n,
                                        scm_t_signed_bits val);

I think that was it from an API POV.

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

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 :)

Andy