Re: SCM_SMOB_TAG smob abstraction

[Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se>]

Greg Badros <gjb@cs.washington.edu> writes:

> Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se> writes:
> 
> > Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> > 
> > > * readability:  The semantics of SCM_SMOB_TAG is immediately clear to a
> > >   reader of the corresponding code.
> > 
> > Really?
> > 
> > What does it mean?
> 
> I think the point is more that SCM_SMOB_TAG has one unambiguous use.
> With SCM_TYP16, various uses are used to mean different things.

Hmm...  SCM_TYP16 always means to extract the type code for
non-immediate objects with 16-bit type tag.  There are SCM_TYP3,
SCM_TYP7 and SCM_TYP16.

I'm still curious what SCM_SMOB_TAG means.

When you implement your own data type, you also implement the type
predicate.  Since this type predicate is used to distinguish the
object from other types in the system it can't be implemented within
the smob abstraction, but must use the abstractions of the type
system:

#define SCM_FOOP(x) (SCM_TYP16 (x) == tc16_foo)

(The tests then look like SCM_NIMP (x) && SCM_FOOP (x).  This is a
 convention in the scm interface.)

This is the *only* place SCM_TYP16 would need to be used.

I think that maybe what Dirk and you are after is that you want smob
to be a sub-type and you want a macro to distinguish a smob from other
smobs.  But then you'd need to make two tests:

#define SCM_FOOP(x) (SCM_SMOBP (x) && SCM_SMOBNUM (x) == smobnum_foo)

I don't see a strong enough reason to change this in the scm
interface.  I *do* think that we should implement a really easy way to
handle user defined types in the gh interface.  That interface would
be based on the new Guile record implementation (the one which will
replace structs).