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.
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.
I don't see any harm in applying Richards patch, though, as things look right now.
Best regards,
Mikael
Hi Richard and all other Guilers, too,
What follows is not code review, but your patch felt like an
opportunity to provide some commentary about the trajectory of Guile
development that I've wanted to share for awhile.
First, I think Guile's default environment is a total mess. It's the
very definition of a junk drawer. There's over 1000 names in the
(guile) module! Contrast this with R7RS-small's (scheme base) module
that only has 200ish. Guile is an old project and I'm sure stuff just
accumulated over the years, but having so much in the default
environment makes it hard to know what a program actually uses because
many things that ought to be explicit imports are not. This makes it a
challenge to move Guile in a more "least authority" direction. As a
rule, I think Guile should *not* add any additional names to the
default environment without an extremely good reason. Because (guile)
is imported implicitly, new names can cause clashes with existing code
that require #:replace to suppress the warning about shadowing core
bindings. For example, the newish 'spawn' procedure collides with
'spawn' in (goblins core) in the Goblins project. I think Guile needs
a (multi-year, multi-major version) plan to deprecate cruft and move
the good stuff into different modules. Give a hoot, don't pollute
(the default environment)!
Second, please please please, no more C! Guile's substantial amount of
C code is a legacy of its origins decades ago, and we need to make it
clear to new users and contributors that new code should be written in
Scheme! The procedures in Richard's patch would be much more elegantly
written in Scheme and it would allow the compiler to gnaw on the code,
too. Those experienced with Guile know that writing Scheme procedures
in C has all sorts of issues, like non-resumable continuations if a C
stack frame is captured, but we could probably do more to discourage
writing C in the docs and stuff. It's also just no fun at all. Who
actually wants to use that C API? Furthermore, every procedure
implemented in C is a challenge for bringing Guile to new places like,
say, WebAssembly. Hoot is unable to import any module from Guile that
loads a C extension. Did you know that (srfi srfi-1) loads a C
extension? Argh! I'm hoping we on the Hoot team will fix that
particular issue soon.
Okay I should be going to bed instead of writing emails. That's all for now!
- Dave