On Sun, Apr 25, 2021 at 4:12 PM Adam Nelson <xxxxxx@nels.onl> wrote:
A suggestion for a global namespace: something under (scheme
...), like (scheme contrib _) or (scheme extra _). That marks the
namespace as "reserved", but still allows as many entries to be
added as necessary without colliding with anything in the official
R7RS.
The (scheme ...), (rnrs ...), and (srfi ...) namespaces are reserved for a reason. If you want to reserve a fourth prefix for another purpose, that's fine, but you shouldn't step on any of the existing ones.
Also, when it comes to development style: will this library be
made up of specifications that each Scheme implements
differently (like SRFIs),
A SRFI isn't just a spec; it's a spec plus a sample implementation, and wherever possible the sample implementation is portable. It may need packaging for a particular Scheme, but that does not mean it needs reimplementation. AFAIK the only SRFI 1 implementation other than the sample one is Chibi's, and that's because it is optimized for code space rather than speed.
(It annoys me that people tend to reject out of hand the idea of using SRFI code that isn't packaged for their implementation, even though it's often perfectly straightforward to do so.)
Of course, "portable" is a relative term. Some sample implementations are portable to R7RS or R6RS Schemes or Schemes with syntax-case. Others are completely not portable but would be trivial to retrofit, like SRFI 169 (underscores in numbers). Then there is SRFI 164 (enhanced multi-dimensional arrays), where the implementation is not portable to anything but Kawa, but for which a portable implementation would be straightforward (most but not all of it could be trivially hosted on top of SRFI 179).