Re: SCM_NEWCELL{2}?

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

On 27 Mar 2000, Mikael Djurfeldt wrote:

> Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> 
> > ***            scm_freelist = SCM_CELL_OBJECT_1 (scm_freelist);\
> 
> Hmm...  I guess this is almost as bad as SCM_CDR, since
> SCM_CELL_OBJECT_n is supposed to return a Scheme object, right?

If I understand the structure of the freelist correct, the
SCM_FREELIST_CDR of a cell in the freelist is a cell pointer to a cell on
the heap.  If we say that there is a type 'free cell', then the pointer
to the free cell is a valid scheme object, just like we say that the SCM
value that holds the pointer to a cons cell or a smob cell is itself a
valid scheme object.

> (Otherwise I agree with Michael about clarity.  Is it really a problem
>  to treat free cells as proper scheme objects?)

It depends on what we want (see below).  Actually, this fine line between
doing it 'pedantically right' and just doing it right is the reason why I
brought the question up.  I also think Michael is right about the
readability, and I think his suggestion to use a SCM_FREELIST_CDR macro is
a good solution, although we might call it SCM_I_FREELIST_CDR to make
clear they are only to be used internally within guile.


There are some pros and cons about doing things 'pedantically right':


As an argument against doing it the hard way, there's the disadvantage
that it will be inconvenient at a lot of places:

If we want to make it a principle, that SCM_CAR, SCM_CDR, SCM_SETCAR
(shouldn't we call these SCM_SET_CAR and SCM_SET_CDR?) only work on valid
scheme pairs, then we would have to create a new cons cell the following
way:

SCM_NEWCELL(pair);            
  *** Caution:  The cell is not a pair _yet_
  *** because the car holds scm_tc_allocated!
  *** Consequently, SCM_SET_CDR is not allowed:
SCM_SET_CELL_OBJECT_1 (cdr);
  *** Also, up to now SCM_SET_CAR is not allowed either:
SCM_SET_CELL_OBJECT_0 (car);
  *** _Now_ it is a valid scheme pair.

Again, this weird code could easily be hidden behind a macro SCM_MAKE_PAIR
or SCM_MAKE_CONS or SCM_CONS for generating a scheme pair.  Surprisingly,
there isn't one yet.  However, we will discover other places where we will 
have to 'work around' such a strict rule.


As an argument for doing it pedantically, there's the point that it would
be possible to turn on an awful lot of debugging possibilities for a guile
user if guile would do it pedantically right internally.  For example,
SCM_CAR could be defined (only in debug mode!) as:

#define SCM_CAR(x) ((SCM_ASSERT (SCM_CONSP (x), ...), SCM_CELL_OBJECT_0 (x)))

thus detecting all misuses of SCM_CAR on non-pair objects.  If in debug
mode SCM_CONSP was defined not only to test if the LSB of the car element
is clear, but also tests whether the cdr is a scheme object, then the
chance for bugs would be even further reduced.

However, obviously SCM_CAR can currently _not_ be defined that way,
because guile internally does not follow these rules.


This is what I meant by saying "It depends on what we want."  I think, as
a lot of code will have to be adapted to achieve a type safe guile, the
additional effort of doing it 'pedantically right' may be acceptable, as
long as clarity does not suffer.  Macros may help get over a lot of the
inconveniences as well as keep the code readable.

Personally, I think it's worth the effort.

Best regards
Dirk Herrmann