The relationship between SCM and scm_t_bits.

[Marius Vollmer]

Hi,

I just got confused about our two 'fundamental' types, SCM and
scm_t_bits.

Variables and function arguments are declared to be of type SCM, while
the words in a cell are of type scm_t_bits.  This results in problems
when dealing with pointers: we can not cleanly cast a pointer to SCM
to a pointer to scm_t_bits, but we might want to do so.

For example, consider a list that is pointed to by a global variable
and some fairly standard way of dealing with singly-linked lists in C:

  SCM head;

  void
  delete_some ()
  {
    SCM *node_ptr = &head;
    if (should_delete (*node_ptr))
      *node_ptr = SCM_CDR (*node_ptr);
    else
      node_ptr = SCM_CDRLOC (*node_ptr);
  }

What should the definition of SCM_CDRLOC be?  Right now it is:

  #define SCM_CDRLOC(x) ((SCM *) SCM_CELL_WORD_LOC ((x), 1))

I.e., it casts a pointer to scm_t_bits to a pointer to SCM.  That,
however, breaks the SCM_PACK/SCM_UNPACK abstraction.  A scm_t_bits
value can only be converted to a SCM value via SCM_PACK, but by using
SCM_CDRLOC, you can sidestep this conversion.

Luckily, code like this works on the platforms that Guile is used on,
but it still is quite unclean, I'd say.

For example, scm_t_bits might be larger than SCM, or SCM_PACK and
SCM_UNPACK might one day need to become non-trivial on certain
platforms (like they were on Crays, I think.)

When the encodings of SCM and scm_t_bits do indeed differ, we should
allow only one of them to be the canonical encoding that is recognized
by the garbage collector.  Right now, this is the SCM encoding (since
scm_mark_locations uses a pointer to SCM to read the stack, etc.)


I propose to remove the need to convert between scm_t_bits* and SCM*
and to allow only SCMs to be in memory.


The words in a scm_t_cell would be of type SCM.  This would mean that
SCM_CELL_WORD_LOC would be removed and replaced with
SCM_CELL_OBJECT_LOC.  Also, SCM_SET_SMOB_DATA (etc) might not be able
to store all scm_t_bits values that it is handed (because scm_t_bits
could be larger than a pointer).  We could make a new guarantee that
says that SCM_SET_SMOB_DATA (etc) can store any pointer that is cast
to a scm_t_bits and any integer that fits into 'unsigned int', say.

The type scm_t_bits would be restricted to temporary values that are
mostly used to test tag bits etc.  They would usually not stored in
data structures and when they are, they can not be expected to
protected the SCM value that they encode when they are scanned
conservatively.

Should we (gradually and with deprecation and everyhing) remove
scm_t_bits from the smob API completely?  I have not thought this
thru, but we might and with something that is not really an
improvement, just different.


Opinions?