This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: deeper constification
- To: clark dot mcgrew at sunysb dot edu
- Subject: Re: deeper constification
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Thu, 30 Mar 2000 18:10:44 +0200 (MEST)
- cc: mdj at mdj dot nada dot kth dot se, mlivshin at bigfoot dot com, guile at sourceware dot cygnus dot com
On Thu, 30 Mar 2000, Clark McGrew wrote:
> set-cdr! vector-set!
> scm_set_cdr_x scm_vector_set_x
> SCM_SET_CDR SCM_SET_VECTOR
I'd rather go for SCM_SET_VECTOR_ELEMENT, because it's not the vector
itself that is set, in contrast to, for example, SCM_SET_CDR. This
difference may also be the reason why the scheme primitive is not called
set-vector!. If that name is too long, we could say SCM_SET_VECTOR_FIELD
which saves us two characters :-)
However, we are facing the problem that the macro naming scheme is in any
case somewhat inconsistent:
SCM_MAKE_<type> should deliver a SCM value, while
SCM_<type> is supposed to make a C value from a SCM value.
So what about SCM_STRING and SCM_MAKE_STRING? OK, these macros do not
exist, but what would they mean if they did? SCM_STRING could be the
equivalent of scm_string, but this is not allowed, since SCM_STRING
should deliver a C value. If, instead SCM_STRING was actually just
reporting the C value, then we could use SCM_MAKE_STRING to construct the
scheme value - if not there were also a scm_make_string primitive.
If the naming scheme is consistent in itself, it may still be confusing
due to differences to the scheme and C function level :-(
I think currently there is not yet 'the' perfect solution found.
Best regards
Dirk Herrmann