Re: The relationship between SCM and scm_t_bits.

[Marius Vollmer <marius.vollmer@uni-dortmund.de>]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

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

[More random thoughts follow...]

Right now, the documented distinction between scm_t_bits and SCM is
that...

     A variable of type `SCM' is guaranteed to hold a valid Scheme
  object.  A variable of type `scm_t_bits', on the other hand, may
  hold a representation of a `SCM' value as a C integral type, but may
  also hold any C value, even if it does not correspond to a valid
  Scheme object.

This is a useful distinction, no doubt.  However, it creates the
situation where user variables have a different type as the cell slots
in the heap.

Now, the distinction between scm_t_bits and SCM is only then practical
when converting between them has zero cost.  SCM_PACK and SCM_UNPACK
can really only be casts that reinterpret the bits.  If this would not
be the case, we would have to remove the distinction to get
performance back.

Thus, scm_t_bits and SCM can be pretty much identical and we can allow
the casting of pointers to them, too.

Better yet, we provide some markup that does the casting for the user.

That is, I now propose to _add_ SCM_CELL_OBJECT_LOC and to _keep_
SCM_CELL_WORD_LOC.  That way, we take over responsibility for getting
the casting right.

Still, I'd want to change the type of fields in the heap from
scm_t_bits to SCM, just so that pointers to SCM are guaranteed to work
across the heap and user variables.  Pointers to scm_t_bits might
still fail on strange platforms and we might then consider removing
SCM_CELL_WORD_LOC on those platforms.

Of course, this whole tedious ponderings can be avoided, as Paul
points out, by just disallowing pointers to SCM or to scm_t_bits
entirely.  But we would need a very good reason for this: using
pointers the way delete_some does is completely reasonable right now.

One reason to disallow pointers would be that a precise garbage
collector that moves objects around can not easily deal with random
pointers into the middle of objects.  However, that's only a
theoretical reason, I don't see getting there any time soon, if at
all.

So, unless a very good reason comes up, I want to allow pointers to
SCM.



> 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);
>   }

[There should be a loop in that function of course. ]


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel