Re: GLOCs are going away.

[Dirk Herrmann]

On 26 Jul 2001, Marius Vollmer wrote:

> In any case, the tc3 tag of structs couldn't just be used for pairs.
> The even tc3 tags are for immediates and in the pointer for
> non-immediates, the odd tc3 tags are in the car of cells.  The struct
> tag is odd, and thus can't be used to tag pointers to non-immediates
> (i.e. pairs).

Yes, you are right.  It would make things too complicated to use odd tags
in SCM values (instead of in cell element #0 only).  One could think of
reducing the bit width of fixnums by one bit (giving 28 bits plus a sign
bit), thus having one tc3 code for non-fixnums, one for fixnums, one for
pairs and one for cells.  However, I am not actually advocating this,
since I don't know about the performance implications.  We should,
however, try to bring guile into a state that testing such a change would
be easy to perform by just changing a small set of macros.  I. e. all
assumptions about fixnum bitwidth should be removed from the code.  It is
a matter of cleanlyness anyway, and I think that guile already has
improved in this direction a lot.

However, I just realized that we _could_ easily provide weak pairs:  
Since Michael has extracted the GC flags from the cells, bit #0 of a
pair's cdr is always 0 (it was used to store the mark bit for pairs during
gc).  This bit could be used to indicate weak pairs.  If it is 0, it's an
ordinary pair, implemented as a single cell.  If it is 1, it is a weak
pair, implemented as a double cell.  For both kinds of pairs, cell element
#0 holds the car, cell element #1 holds the cdr.  In case of weak pairs,
cell element #2 holds information about the type of weak pair and cell
element #3 is used for linking weak objects together during gc.

Code that uses SCM_CAR and SCM_CDR only for accessing real pairs would not
have to be changed at all, because SCM_CDR could be redefined to clear bit
#0 when extracting the SCM value.  Analogously, SCM_SETCDR would, before
writing the value to the cell, set bit #0 according to the value that is
already found in the car of the cell.

A large variety of different types of weak pairs are possible if cell
element #2 of a weak pair is treated as an index into two function tables
(well, not necessarily function tables:  a hard-coded type dispatch could
also be used).  Function table 1 holds a set of mark functions, function
table 2 holds a set of functions to be performed on the cell after
marking, if the cell is found on the weak chain.

Possible mark functions:
- Mark the car, but not the cdr.
- Mark the cdr, but not the car.
- Don't mark neither car nor cdr.

Possible post-mark functions (examples):
- If the car is unmarked, overwrite the cell's car with some value.
- If the car is unmarked, overwrite car and cdr with some values.
- If the car is unmarked, copy the contents of the cell pointed to by the
  cdr into car and cdr.  (Usefull to automatically shorten weak
  lists.  Note, however, that this operation as well as access to such 
  lists has to be protected by a mutex.  Thus, it may be easier to have
  code that accesses the lists do the copying instead of doing it during 
  gc.)
- If the cdr is unmarked, overwrite the cell's cdr with some value.
- If the cdr is unmarked, overwrite car and cdr with some values.
- If either car or cdr is unmarked, overwrite the corresponding cell
  element with some value.
- If either car or cdr is unmarked, overwrite car and cdr with some
  values.
- ...

This will allow to implement all kinds of weak lists, weak hash tables and
lots of other stuff.  The current (mis)use of weak vectors for this kind
of functionality could be eliminated.

IMO, having weak pairs that can be used transparently in C and scheme code
is a very nice feature.  If there is interest, I could give it a try.  
(Well, there are so many other things I'd like to do, but for which I
currently don't find the time :-)

Best regards,
Dirk Herrmann