Re: deeper constification

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

On 30 Mar 2000, Mikael Djurfeldt wrote:

> > > Just a question: If we're making an exception from the naming
> > > convention in order to be consistent with Scheme, how do you feel
> > > about the fact that we're anyway not using the Scheme name translation
> > > convention?  (SCM_VECTOR_SET vs SCM_VECTOR_SET_X)
> > 
> > I'd say if we are to translate, then let's translate.  so
> > SCM_VECTOR_SET_X seems to be the best choice.
> > 
> > but in general, having both SET and _X in one name seems verbose.
> > hmm...  is there any agreement wrt macro names obeying the same rules
> > as function names?
> 
> No, on the contrary: We have never used _X in macro names.  Example:
> Old SCM_SETCAR and new SCM_SET_CAR.  It would probably be irritating
> to write that _X all the time...  Also, we would have to change
> essentially *all* current SET macros in order not to be inconsistent.
> 
> Maybe this tells us that there is no big win in departing from
> convention in order to be similar to Scheme names: We won't go all the
> way anyway...

We will, however, need some rules to make things consistent.  Guile will
in any case provide a large API, consisting of the scheme functions, the C
functions and the C macros.  Some API elements have an equivalent on all
three levels, some don't.  The question is, how can we make guile _easy_
and _fun_ to use?  Whoever wants to embed guile in applications wants
something that can be learned fast, because the primary concern is the
developers own application, and not guile.

I personally never had a problem with long names:  You only _write_ code
once, but you and others will read it several times.  Thus, the typing
inconvenience of long names is not the problem.  But as Mikael has once
pointed out, there may also a reading inconvenience with long names or
names that are structured 'strangely'.

Currently I am not decided yet about what I think of the _X issue.  It
would, however, not be a big problem to provide additional _X macros for
some time.  I also have the (maybe naive) hope that changing such macros
could be done using perl.  Thus, we should know what we want as soon as we
are going to release an official API, but it should still be alright to
use an intermediate solution at the moment.

BTW:  At the moment, the whole macro naming issue is quite inconsistent
anyway:  SCM_BOOL for example creates a SCM value, _not_ a C boolean
value.  Otherwise, macros that create SCM values typically contain some
MAK or MAKE component.  SCM_CONSP is also quite strange:  SCM_PAIRP (or
SCM_PAIR_P) would be more similar to the scheme level primitive...

Best regards
Dirk Herrmann