Re: Integer conversion proposal

[Dirk Herrmann]

On 23 Sep 2001, Mikael Djurfeldt wrote:

> 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?

Gary's suggested generic functions are a very good idea.  Thus, a minimal
set should, IMO, include:
* int and uint.  Since int is (IIRC) the natural machine word size,
  working with ints is typically fast.  Conversions to 'smaller' types
  like shorts or chars is also a matter of very few machine instructions.
* foo and ufoo.  These are placeholders for the signed and unsigned
  variants of the C99 typedefs that represent the 'largest' type that the
  compiler supports directly - I just happen not to recall their
  names, sorry.  The advantage is, that you can simply use casting (plus,
  certainly, some range checking) to convert values of this type to any
  other compiler supported integral type.
* Gary's suggested generic conversion functions, which go even beyond the
  set of compiler supported types.  However, replacing either of the two
  other function pairs above with these functions will probably result in
  a performance degradation - except you could implement these functions
  using some clever macro magic.

I don't mind having additional conversion funcions as well.  Support for
longs is probably not a bad idea - they are, however, not essential given
the function pairs above.

> 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.

OK, then it is probably wisest to deprecate them, and during the phase of
deprecation just keep the behaviour as it was before (as you say it).

> > 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.

Yes, after thinking a second time about it, I realize that it does not
make much sense this way.  However, what we should think about is to
provide a function scm_integer2xxx, which will accept any integer (i. e.
exact or inexact) and convert it to an integral type xxx.  In this case,
there is no big question about the semantics:  Everything that fulfills
integer? will be accepted.  Inexact integers will simply be coerced - what
else would a user typically do about them anyway?  In contrast to
scm_num2xxx, these functions would be properly named, thus I think
providing these functions provides some comfort without compromising
cleanlyness.

In a similar way, scm_{exact_}?rational2{float|double} and
scm_{exact_}?real2{float|double} could make sense - even if guile does not
support all of these currently.

Best regards
Dirk Herrmann