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