Re: scm_num2int change

[Mikael Djurfeldt]

Bill Schottstaedt <address@hidden> writes:

> > > Where in "num" does it say "exact num"?
> > Where in "num" does it say "integer"? :)
> 
> I've always suspected the Guile developers don't actually use Guile.

(Actually, the larger part of my contributions has been driven by my
needs as a Guile user.  I have been using Guile's Scheme and C level
interfaces in applications since before Guile was Guile.)

> If its name is num2int the obvious thought it that it's converting
> a scheme integer to a C integer.

It's name suggests that it converts a Scheme number to a C integer.
Which numbers to accept for conversion is not obvious just from the
name.  I argue that it is more *useful* to restrict this set of
numbers to exact integers for these particular conversion functions.

Note that most of the scm_ interface is used to implement Guile
itself.  In Guile and R5RS the *common* case is that primitives don't
accept inexact integers.

If users have a strong need for the kind of conversion function you
suggest, we can implement and provide that.

But the reasons why it is the common case in Guile and R5RS not to
allow inexact integers ought to hold also in applications using Guile.

One reason is this: Primitives which allow inexact integers but not
other inexact reals tend to lead to buggy programs.  Note that as long
as a computation results in, for example, 3.0, the primitive will
gladly swallow its argument.  But, for some other input data, the
computation might result in 29.999999 instead of 30.0 => error!
It is therefore generally better to require the programmer to
explicitly perform the conversion into an exact value.

> If I have a C procedure taking SCM args (you really should write one
> someday), and I ask is this an integer, and I get "yes", I should be
> able to say "give me its value as a C integer" and not have to worry
> about whether it's exact

Maybe we should provide a function scm_exact_integer_p?

> (which is an unrelated issue -- it is simply a bug in Guile that
> (exact? 3/4) returns #f).

This is not a bug.  According to R5RS, an implementation is allowed
not to support rational numbers.  Also 3/4 is valid syntax for a real.

> But, I can tell when I'm talking to a brick wall.

Yes, I can be rather stubborn when I see why a certain solution is
good.  :)

> How about providing a function or macro that returns #t if its arg
> is handlable by whatever is today's version of the scm->C conversion
> routine

That's a good idea.  Such a predicate should do the proper range
checking as well.

> -- at this point I have a huge pile of macros trying to clean up
> after the mess you're making.

In this case, I'm very well aware that I'm not creating mess, but
rather cleaning up the mess which was there before.  I think the
previous situation with primitives accepting inexact integers for some
parameters but not in others is a very clear example of such mess.

Mikael