This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: mildly incompatible change


On Thu, 23 Jul 1998, Jim Blandy wrote:

> I've just committed the following change to Guile.  If you have C
> code which defines new smob types, please check your mark functions to
> make sure they're okay.
> 
> 
> >From guile-core/NEWS:
> 
> * Changes to the scm_ interface
> 
> ** The semantics of smob marking have changed slightly.
> 
> The smob marking function (the `mark' member of the scm_smobfuns
> structure) is no longer responsible for setting the mark bit on the
> smob.  The generic smob handling code in the garbage collector will
> set this bit.  The mark function need only ensure that any other
> objects the smob refers to get marked.
> 
> Note that this change means that the smob's GC8MARK bit is typically
> already set upon entry to the mark function.  Thus, marking functions
> which look like this:
> 
> 	{
> 	  if (SCM_GC8MARKP (ptr))
> 	    return SCM_BOOL_F;
>           SCM_SETGC8MARK (ptr);
> 	  ... mark objects to which the smob refers ...
> 	}
> 
> are now incorrect, since they will return early, and fail to mark any
> other objects the smob refers to.  Some code in the Guile library used
> to work this way.

I welcome this change, since it frees the user from fiddling with such
beautiful :-) implementation details as SCM_GC8MARKP.

I suggest that a similar step be taken in the test for smob types (only in
the C API, I learned that a scheme level smob? predicate was no good):
What about adding some definition similar to

#define SCM_SMOB_P(scm, tag) \
    (SCM_NIMP(scm) && SCM_CAR(scm) == tag) 

instead of letting the user perform this test, thus having to deal with
SCM_NIMP and the fact, that the car of the smob holds the tag? Using a
macro would even allow to encode the type tag in some way, thus
making it easy to overcome the 256 smob barrier. Obviously, another macro
for extracting the smob data would be needed as well to achieve optimum
abstraction.

Best regards, 
Dirk Herrmann