Re: The relationship between SCM and scm_t_bits.

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> Marius Vollmer wrote:
>
>>Hi,
>>
>>I just got confused about our two 'fundamental' types, SCM and
>>scm_t_bits.
>>
> The two types were introduced in order to create a level of
> abstraction between code, that operates on the encoding of scheme
> types, and code that only requires on API elements to do so.
> [...]

Yep, thanks for reinforcing this.  The purpose of scm_t_bits as it is
currenly documented in the manual is different, however: it is the
type that can hold arbitrary words, not just valid SCM values.  The
first word of a smob would be a scm_t_bits since it is not a valid SCM
value, for example.  I was confused by these two distinctions between
the two types.

>>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);
>>  }
>>
> Such code should be avoided. [...]

Yes, probably.  But we currently support this style and Guile uses it
itself.  However, the way we were casting pointers around did not
properly respect the disctinction between SCM and scm_t_bits: we
didn't make the guarantee that you could meaningfully cast a
scm_t_bits* to a SCM*, yet we would rely on it.

Instead of disallowing working with SCM* pointers, I have fixed the
type confusion.  This was the smaller change by far.

But of course, this does not mean that we can not at one time disallow
the use of SCM* pointers.  But that would be a much bigger decision
than I would want to make now, while (slowly) zooming in on 1.8.

> By modifying SCM values through SCM pointers you skip the write
> barrier. When switching to generational GC, such code would have to
> be fixed, either to avoid using the pointer access, or to add some
> operations that perform, what the write barrier would have
> done. Thus, in order to keep the number of places small which
> require such fixing later, I try to avoid using SCM_CDRLOC etc.

Yes, I fully agree here.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405