[Top][All Lists]
[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