[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memory.text
From: |
Dirk Herrmann |
Subject: |
Re: memory.text |
Date: |
Sun, 25 Nov 2001 23:35:17 +0100 (MET) |
On 24 Nov 2001, Marius Vollmer wrote:
> Improving memory handling in Guile
> ----------------------------------
[...]
Very nice. I like the concept as well as the function names you are
suggesting.
> Cell allocation and initialization
> ----------------------------------
[...]
> SCM scm_newcell_init (scm_bits_t car, scm_bits_t cdr)
> {
> SCM z;
> if (SCM_NULLP (scm_freelist))
> z = scm_gc_for_newcell (&scm_master_freelist,
> &scm_freelist);
> else
> {
> z = scm_freelist;
> scm_freelist = SCM_FREE_CELL_CDR (scm_freelist);
> }
> SCM_SET_CELL_WORD_1 (z, cdr);
> SCM_SET_CELL_WORD_0 (z, car);
> scm_remember_upto_here (cdr);
> return into;
> }
What about naming the function scm_make_cell, or scm_new_cell? If that
will be the only way to get a new cell in the future, the _init postfix
will be unnecessary. Further, scm_make_<foo> seems to fit better into the
common way of naming functions in scheme.
There is, however, something we should think about: car and cdr are, in
your example, of type scm_t_bits. If the new cell won't be a pair we
should not use the terms car and cdr, but rather word0 and word1 or
something. Further, we should not use word1 as an argument for
scm_remember_upto_here, since that only accepts SCM values. It is,
however, not clean to coerce word1 to a SCM value with SCM_PACK either,
since that turns something into a SCM value that not necessarily
represents a real SCM object. Hmmm?
Best regards
Dirk Herrmann
- memory.text, Marius Vollmer, 2001/11/23
- Re: memory.text,
Dirk Herrmann <=
- Re: memory.text, Marius Vollmer, 2001/11/25
- Re: memory.text, Dirk Herrmann, 2001/11/26
- Re: memory.text, Marius Vollmer, 2001/11/26
- Re: memory.text, Dirk Herrmann, 2001/11/26
- Re: memory.text, Rob Browning, 2001/11/27
- Re: memory.text, Marius Vollmer, 2001/11/27
- Re: memory.text, Thien-Thi Nguyen, 2001/11/27
- Re: memory.text, Dirk Herrmann, 2001/11/29