Re: SCM_NEWCELL{2}?

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> 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.

Yes, you're right.

> > (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.

I buy your arguments for coding "pedantically right", and think we
could go through with such a change.  This is a big decision, though,
and we should hear what Maciej and the others have to say first.

I also think we should change SCM_SETCAR to SCM_SET_CAR.  But while
doing all these changes, it's important that we keep track of backward
compatibility so that we don't break old applications more than
necessary.  We should, for example, preserve old macros and try to
make sure that only the "debugging modes" will break compilation on
violations, at least in the beginning.