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 <dthompson2@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
>
>