[Top][All Lists]

[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 21:35:10 +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:
>> 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?


> Put another way: these functions are useful for the same reasons that
> that GMP is useful for more than just writing interpreters.  Yes, some
> people want to write the bulk of their code in C, even when they are
> using such features.

OK, fair enough.

I think I’ve already sufficiently distracted you, and I’m fine with you
committing the patch (and after all, we’re talking of one C function.)

> We cannot force people to use Scheme.  If we wish for libguile to be
> attractive for use by projects primarily written in C, we ought to
> extinguish this unfortunate recent tendency to say "people ought to be
> writing Scheme not C", and we ought to stop using that as an excuse to
> block improvements to the C interface.

It’s become our motto!  :-)

I don’t want to block improvements to the C interface, and I agree that
this convenient C interface has been one of Guile’s strengths, which we
should keep.  But I wouldn’t want them to block improvements to the
Scheme implementation.

First, maintaining the compatibility of C functions can be hard, at
least harder than maintaining a Scheme interface because Scheme has
optional arguments and so on.  Second, the C interface can expose
details that hinder improvements of the Scheme implementation—e.g.,
‘scm_values’, dynamic-winds, etc.


reply via email to

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