Re: GNU Guile 2.1.7 released (beta)

[Andy Wingo]

On Thu 23 Feb 2017 19:54, Andy Wingo <address@hidden> writes:

>  * Foreign objects.  In or out?  Let's start a subthread.

SMOBs have many problems:

 * they are limited in number (255 including guile's smobs)

 * SMOB types are only creatable from C (in a time where anything done
   in C should be doable in Scheme)

 * SMOBs can only be constructed from C

 * SMOB fields are only accessible from C

 * SMOB markers are ~~~~~~gnarly~~~~~~~

 * SMOB finalizers are tricky.  Well finalizers are tricky in general
   but for SMOBs specifically they can see other objects that have
   already been finalized (or which are being concurrently finalized)
   and thus have called their own free() functions, which can corrupt
   memory.

The situation with SMOBs is good if you don't specify mark procedures
(practically deprecated since Guile 1.8) and your finalizer doesn't
touch additional GC-managed objects that themselves have finalizers
(hard to determine) and if your finalizers are threadsafe (ha ha ha ha
ha ha).  The manual didn't really discuss any of these problems.  And
then there's the issue of the very 1980s interface of SMOBs.  Let's not
mention markers!

So you look at this whole situation and, this is an interface headed for
deprecation, right?  I mean surely we can do better -- or at the very
least we can do the same but in a more comprehensible way.  So I made
the "foreign object" interface to do just that.  See the docs here:

  
https://www.gnu.org/software/guile/docs/master/guile.html/Defining-New-Foreign-Object-Types.html
  https://www.gnu.org/software/guile/docs/master/guile.html/Foreign-Objects.html

The former is in the introductory "using Guile from C" section and the
latter is the reference.  Compare to 2.0:

  
https://www.gnu.org/software/guile/manual/html_node/Defining-New-Types-_0028Smobs_0029.html
    - it tells users to use mark functions (this is bad advice in
      general)
    - it doesn't mention much about threads when it talks
      about finalization
  https://www.gnu.org/software/guile/manual/html_node/Smobs.html#Smobs
    - not really linked to from the previous section??  (This one is in
      "API" and the other is in "Programming in C")
    - recommending scm_gc_free
    - scm_markcdr????

So foreign objects fixes the problems mentioned above and also makes the
whole facility more explainable.  It effectively replaces SMOBs; it's a
nicer interface in all regards.

I think it would be fine to continue having foreign objects going
forwards.  It's supportable just fine and strictly better than smobs
(unless you need a mark function, in which case SMOBs are still there
for you).

It could be that these foreign objects don't fulfill all use cases, such
as packed structs with C layouts.  Oh well; can't win them all.  We can
work on this more in the future I think.

Thoughts? :)

Andy