pika-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pika-dev] alists, list issues


From: Tom Lord
Subject: Re: [Pika-dev] alists, list issues
Date: Fri, 6 Feb 2004 10:13:23 -0800 (PST)

    > From: Andreas Rottmann <address@hidden>

    > Tom Lord <address@hidden> writes:

    > > Just what you'd think:

    > >      scm_ass{q,v,oc}_ref

    > >      scm_del{q,v,ete}

    > And scm_ass{q,v,oc}_set_x for ass{q,v,oc}-set!  ?

Yeah, I think so.

Sigh.

Some of the existing names don't use the _x convention but they
probably should.

(The mistake I made: In systas, the _x convention is used
consistently.  But in Pika, I was initially thinking that, where it
was redundent, I'd drop it (hence, scm_set_pair_car and
scm_set_vector_elt).  The problem is, as the assoc list examples show,
it's _never_ truly redundent.  Every mutating operation has a
potential non-mutating analog (`assoc-set!' and `assoc-set').

So, really, Pika should just go back to more regular names
(eventually, no big rush -- renaming functions is easy):

        scm_set_pair_car => scm_set_car_x

        scm_set_vector_elt => scm_set_vector_elt_x

And, incidentally, the reason it's scm_set_vector_elt_x and not 
scm_vector_set_x is because the latter name is reserved for a function
that takes a Scheme value for the index rather than a C integer.   I
don't mind special-casing predicates, but don't want to do more than
that.    So:

   char? => scm_is_char
   set-car! => scm_set_car_x
   vector-set! => scm_vector_set_x (which calls scm_set_vector_elt_x)

)


-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]