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

[Detlev Zundel]

Hi Noah,

> You make good points, but I disagree. I think the ideal for Guile
> should be a situation where C and Scheme can be used basically
> interchangeably, with Guile providing the glue in between.

Of course one can disagree, but then it immediately follows that there
is no "ideal for guile" which every developer can agree with, right?
Every developer will define this differently from his perspective.

> A situation like that would certainly lead people to write as much as
> possible in Scheme, because if C and Scheme are really interchangeable
> then all you gain by writing in C is extra verbosity. 

Actually I don't belive that.  If C and Scheme are interchangeable,
people will use the context they know better, so I'd expect more C to
emerge.

> But people might still have things written in C, maybe because the
> program was originally written in C and is slowly adding in Guile
> bits. Maybe someone needs to write parts of the program in C because
> Guile is still not as fast as statically-compiled C code, but would
> like to use exact_integer_sqrt in that C code.
>
> Therefore I think we should provide a convenient way to access as much
> of Guile's functionality from C as possible. Things like continuations
> might be quite difficult, and I think no one would blame us if C code
> couldn't use those, but generally useful functions like
> exact_integer_sqrt should certainly be available.

Maybe it doesn't make sense to continue this discussion on a theoretical
basis.  Because on a theoretical basis I would probably cite the rule of
modularity or even Antoine de Saint-Exupery:

  Perfection (in design) is achieved not when there is nothing more to
  add, but rather when there is nothing more to take away.

> I do see your point about C functions being difficult to maintain, but
> I think they are no more difficult to maintain than Scheme functions -
> either way, we introduce a function, and then we must make sure that
> the function with that name has the same functionality for a while.
> (Except that Scheme supports versioned libraries. But I think we don't
> currently use that feature, so it is irrelevant.) It would be nice to
> have a more flexible way of interfacing C and Scheme things, but this
> is the interface we currently have, so I think we should go ahead and
> support it as much as we can.

When we offer more C hooks into guile, we will eventually end up with
projects being entangled more closely with the guile library. Thats a
simple fact and users will expect that this will be supported for some
time.  From different programming projects I know the pain of supporting
such constructs and the amount of programming that they actually
_prevent_ from being done, because new contributors very often shy away
from the possibility of breaking existing code.  I've seen it more than
once that fixes and improvements eventually were not done because of
such entanglements.  (A good regression test alleviates this problem and
as far as I can see guile has such tests, so maybe this point does not
weigh too heavy here).

But in the end maybe it is a question of whether one sees guile as a
scheme interpreter with the possibility to interface easily with C or if
one thinks of guile as a C library with a language built in.  For me it
is the first choice but you seem to lean towards the latter.

-- 
Perfecting oneself is as much unlearning as it is learning. 
                                        -- Edsger Dijkstra