This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
SCM_NEWCELL{2}?
- To: Guile Mailing List <guile at sourceware dot cygnus dot com>
- Subject: SCM_NEWCELL{2}?
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Mon, 27 Mar 2000 16:25:27 +0200 (MEST)
Hi!
In order to get incrementally rid of the type inconsitencies in guile I'd
like to change the SCM_NEWCELL macros as the following example
shows: (the lines that change are marked ***)
The current definition:
#define SCM_NEWCELL(_into) \
do { \
if (SCM_IMP (scm_freelist)) \
_into = scm_gc_for_newcell (&scm_master_freelist, \
&scm_freelist); \
else \
{ \
_into = scm_freelist; \
*** scm_freelist = SCM_CDR (scm_freelist);\
*** SCM_SETCAR (_into, scm_tc16_allocated); \
} \
} while(0)
becomes:
#define SCM_NEWCELL(_into) \
do { \
if (SCM_IMP (scm_freelist)) \
_into = scm_gc_for_newcell (&scm_master_freelist, \
&scm_freelist); \
else \
{ \
_into = scm_freelist; \
*** scm_freelist = SCM_CELL_OBJECT_1 (scm_freelist);\
*** SCM_SET_CELL_TYPE (_into, scm_tc16_allocated); \
} \
} while(0)
The reason is, that neither the cells on the freelist from valid scheme
pairs (i. e. SCM_CONSP is wrong), nor is the newly allocated cell a valid
scheme cell (same reason). Thus, accessing cells from the freelist with
SCM_CDR is not appropriate, nor is SCM_SETCAR appropriate to access the
allocated cell. The other SCM_NEWCELL definitions would have to be
changed accordingly.
Please note that the resulting code will not be different (I hope
:-). It's just the type strictness that (I think) will be improved.
Are there objections to my interpretations of scm_freelist and
scm_tc16_allocated and the consequences for the SCM_NEWCELL macros? If
not, I will apply the changes.
Best regards
Dirk Herrmann