The Guile junk drawer and a C plea (was: [PATCH] Add nondestructive delq1, delv1, and delete1.)

[Thompson, David]

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