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: Ludovic Courtès
Subject: Re: [PATCH] Fix the R6RS exact-integer-sqrt and import into core guile
Date: Sat, 09 Apr 2011 16:07:21 +0200
User-agent: Gnus/5.110015 (No Gnus v0.15) Emacs/23.3 (gnu/linux)

Hi Mark,

Mark H Weaver <address@hidden> writes:

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

As I said, I wasn’t fond of it.  However, it’s true that C code often
has to deal with modules to glue things together, so I can understand
that it makes people’s lives easier.

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

OK.  I was thinking that I’d use C when dealing with fixnums or floats,
and let Guile manage bignums and similar—in which case writing C doesn’t
seem to help much.

Do you think there are use cases for using this interface from C?  (It’s
a real question, I thought “no”, but I may be wrong.)

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

Oh, I’m fine with having a C implementation of this function; I was just
wondering whether the C function should be public.

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

OK, understood.

It’s true that ‘scm_values’ sucks, but then if when can avoid exposing
to C functions that return multiple Scheme values, all the better!  :-)

What do you think?

Thanks,
Ludo’.



reply via email to

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