Re: Integer conversion proposal

[Mikael Djurfeldt]

Dirk Herrmann <address@hidden> writes:

> Which target types should we support?

I agree that we can be rather "economic" and only support the most
common types.  What about supporting "int", "long", ulong" (because
the last two are so oftenly used) + the two more generic functions
which Gary suggested?

> In addition, as suggested by Michael, we should provide checking variants

Sorry!  My proposal had a bug.  I only meant to suggest that we could
rename the *current* versions introduced by Michael.  I intended keep
the checking variants, just renaming them.

> Just for clarification:  I assume that these functions will accept any
> exact or inexact real number, right?  That is, any number which does not
> have an imaginary part could be converted using these functions.

Yes.

> > * Introduce a macro SCM_COERCE_EXACT(N) which returns its argument
> >   verbatim for all types except inexact numbers for which an exact
> >   value is returned if possible.  (Note that this macro can be made
> >   very efficient.)
> 
> Just for clarification:  Which input types should SCM_COERCE_EXACT
> accept?

All types.

> Is any typechecking done?

No.

> How does the coercion work?

If the argument is an inexact integer => coerce, otherwise return
verbatim.

> (I'd suggest rounding plus inexact->exact).

But this is again a change in semantics.  The idea in the proposal was
to keep the old semantics for scm_num2long for people who want it.
Accepting *any* real seems too generic.  The decision how to round a
number definitly needs programmer supervision.

> The question is, should we provide such functions for user convenience?  
> Maciej's comment about complex numbers indicates that scm_num2int and
> friends should be deprecated

That is my feeling as well.

> It does not make sense to convert complex
> numbers with non-zero imaginary part to int.  However, it seems to me that
> scm_real2int (just a better name for scm_num2int) for example might make
> sense, given that the coercion behaviour is cleanly documented.

I'm really not so sure that's a useful function.  When you need
something like that, it seems better to supply a function to round +
convert into exact and combine that function with a
scm_exact_integer2xxx function.

Best,
Mikael