guile-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Fix the R6RS exact-integer-sqrt and import into core guile


From: Mark H Weaver
Subject: Re: [PATCH] Fix the R6RS exact-integer-sqrt and import into core guile
Date: Fri, 08 Apr 2011 14:18:12 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

address@hidden (Ludovic Courtès) writes:
>> Why do you think the C interface should be kept internal?  Most of the
>> core arithmetic procedures provide public C interfaces.  Why should
>> exact-integer-sqrt be treated differently?
>
> Because:
>
>   1. I think we shouldn’t augment the C API unless strictly necessary,

We recently added several convenience functions that weren't strictly
necessary.  Do you think that was a mistake?

>      because the idea is to write Scheme, not C,

I've been hearing this more and more lately.  Of course most of us here
prefer to write Scheme, but Guile's strong interoperability with C, and
in particular its extensive C interfaces, has always been one of its
distinguishing characteristics.

For better or worse, there are many people who prefer to write the bulk
of their programs in C, and to use Guile for user extensibility and
perhaps also as a general purpose library for various bits of
functionality contained therein.

The function in question (which computes the exact floor of the square
root along with the remainder, analogously to the number-theoretic
division operators) is not part of the standard C library, and is not
entirely trivial to implement efficiently in the general case, when
bignums are included.  I can easily imagine that a program might want to
use this function from C.  If we don't provide this interface, there
will be no efficient way to access it from C.

>      and because of the maintenance cost.

Unless we do not wish to support the R6RS, we have no choice but to
maintain this function indefinitely.  It is true, we could in theory
eliminate the C implementation at some point in the future, but that
would be rather inefficient.

That is especially true since it is the basis for fixing the generic
sqrt procedure to properly handle large exact integers and rationals,
and to return exact results when possible as is done in Gambit.  I
already have a patch for that, but have not yet submitted it.

>   2. This particular function is “unusual” in that it returns ‘void’ and
>      takes pointers to SCM.

This is the same style of C interface we provide for the new set of
number-theoretic division operators that return both quotient and
remainder, scm_floor_divide et al.  Wingo requested that this be the
preferred C interface for returning multiple values, in order to avoid
unnecessary heap allocation.  In fact, he wisely objected to my division
operator patches until I modified them to use this style of interface.

     Best,
      Mark



reply via email to

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