pika-dev
[Top][All Lists]
Advanced

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

Re: [Pika-dev] Naming issues in implementing numbers


From: Tom Lord
Subject: Re: [Pika-dev] Naming issues in implementing numbers
Date: Sat, 10 Jan 2004 22:54:53 -0800 (PST)


    > From: Matthew Dempsky <address@hidden>

    > Alright, I've added about 1000 or so lines of code to the pika to
    > implement numbers and all (not finished yet, but it's quickly
    > approaching there), and I've come across a few issues...

    > First, I want to know if there are any objections to renaming files in
    > libscm-numbers like fixnum.* and double.* to cvt-fixnum.* and
    > cvt-double.* (with appropriate changes to the remaining files in both
    > libscm-numbers and libscm-numbers-reps).

    > The reason for this is two fold: first, I think it would help clear up
    > that the files simply perform a conversion between internal
    > representations representations and C representations -- at first I
    > thought the functions were meant to define constructors and accessors,
    > but as simple a change as this might make that a little more clear.

    > Second, in case the first wasn't strong enough, I would like to define
    > two new types, bignum and bigrat, and, following the pattern defined
    > in libscm/ and reps/, should name their source files bignum.* and
    > bignum-imp.* and bigrat.* and bigrat-imp.*, however, this conflicts if
    > I want bignum and bigrat conversion functions.

    > (I considered further recommending to rename the functions to
    > scm_cvt_number_to_fixnum and so forth, but I'm not sure that's
    > necessary.)

I have no objection to such renames.  Thank goodness we aren't using
CVS :-)


    > The second change I want to make is simply to rename fixcplxrat to
    > fixratcplx.  The second seems a more consistant naming pattern - any
    > complex type is defined as it's component types name with a 'cplx'
    > suffix.

Ok.

    > Finally, between the r5rs defined scm_is_complex and
    > scm_make_rectangular functions, it impairs my choice of names that I
    > can use consistantly (to define a scm_make_<type> constructor and
    > scm_is_<type> predicate), but I just recalled Larceny uses rectnum so
    > I'll probably use that unless someone can recommend a better one.

That's fine too.

    > Also, is using scmx_vtable_object_vtable "portable" for use in
    > libscm-numbers-reps?

You can do that for now.  I guess that you want it instead of
`scm_value_vtable' for efficiency reasons?  The right thing (slightly
obsessively), i think, is to make `scm_vtable_object_vtable' which is
defined only over vtable objects, is basically equivalent to
scmx_vtable_object, and returns the same answer as `scm_value_vtable'
for the intersection of their domains.


Yr favorite "Yes man",
-t




reply via email to

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