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

[Noah Lavine]

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.

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

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.

Noah

> Although I'm more a passive observer on this mailing list, I still want
> to add a little bit to this discussion.  Personally I very much embrace
> and support this "write Scheme rather than C" stance being taken by some
> of the project maintainers.
>
> Although it is an obvious truth, it helps to remember that no project
> can serve all wishes of each and every developer.  As a consequence it
> is clear that a project has to make a choice of direction of where it
> wants to _lead_.  This direction should of course reflect the needs of
> the project itself, i.e. maintainability, testability, documentability,
> etc.
>
> One should also be aware that the APIs offered can severly influence
> people in their own designs.  Let's face it, most developers (including
> myself) are rather lazy and try to do as little changes as possible
> _even_ if larger changes would be _positive_ for the work as such.  A
> project _can_ (and I'd say should) force people at least to think about
> such changes by publicly offering more clean abstractions.  A project
> can surely transport a message to new users this way.
>
> And please, let us not try to consider theoretical needs of potential
> guile users but rather concentrate on the needs of the guile maintainers
> and current users.  The time to discuss things which can negatively
> influence maintainability and testability is the time when an actual
> potential user comes along, not earlier.
>
> As a side example, think of how the Linux kernel would have dissolved to
> be an unmaintainable nightmare if every system call suggested on the
> mailing list would have been adopted.  A project is well advised _not_
> to follow each and every cry of every developer.  That's because crying
> is easy, but maintaining ain't ;)
>
> Ok so much for my "bystander view".  Thanks for listening.
>  Detlev
>
> --
> These days, even the most pure and abstract mathematics is in danger
> to be applied.
>
>
>