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 Den lör 29 juni 2024 04:53Thompson, David <dthomps...@worcester.edu> skrev: > 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 > >
