Hi Mikael, On Sat, Jun 29, 2024 at 3:38 AM Mikael Djurfeldt <mik...@djurfeldt.com> wrote: > > Your two points sound good. > > However, I personally hope that Guile will continue to be friendly towards > those using it as an embedded language. There, a C API is important. There > *is* a downside in moving to Scheme from that perspective, but that is fine > as long as it is easy to call Scheme from C. The typical use case is when a > binding in the application which use Guile as embedded language needs to > manipulate Scheme data in its arguments in order to interpret them.
To clarify: I am not saying that Guile's C API should go away. What I am saying is that we should not introduce new standard library procedures that are implemented in C. Guile is already slowly replacing C with Scheme (this is how we got suspendable ports, for example) and I'd like to see that trend continue. This work is being accelerated, in a way, it's just happening in the Hoot project. Whenever we try to port a new program that calls a (guile) procedure implemented in C, we write our own equivalent in Scheme. For example, I think we already have most, if not all, of libguile/list.c covered. We could upstream that code at some point. > Regarding the junk, I very much agree. I also look forward to getting rid of > ice-9 :). As has been spoken about here previously, I suggest that we design > a new module hierarchy, introduce aliases for module bindings, and still > supply the old module hierarchy during a few years for backward compatibility. While I didn't explicitly bring up the ice-9 namespace, I am in favor of transitioning away from it. It confuses too many newcomers. The manual explains it, I think, but no one sees that and it's still a frequently asked question. I enjoyed reading Cat's Cradle in high school English class as much as any US public school student, but the fun reference isn't worth the confusion that it causes. But to be very clear: Shrinking the exports in the (guile) module is orthogonal to transitioning away from the ice-9 namespace. I wouldn't want the two conflated because the latter is much more controversial than the former, I think. > I don't see any harm in applying Richards patch, though, as things look right > now. I think the new procedures should simply be implemented in Scheme rather than C. Those destructive procedures are already there, might as well have nondestructive ones that are much more useful. And you'll save me porting 3 additional procedures for Hoot. ;) - Dave
