Hi :) Thanks for taking the time to look at the issue!
On Tue 07 Mar 2017 14:44, l...@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. 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
