>> The default environment is irrelevant to most Scheme libraries, since
> it is irrelevant to any library defining modules with
> ‘define-module’, ‘define-library’ or ‘library’ forms (which is pretty
> much the only reasonable way to define modules unless you are making
> your own system). This already reduces a lot of compatibility
> concerns. An important exception is anyone doing ‘eval’ or compiling
> expressions (think anyone doing the equivalent of “guile -l
> script.scm”.
>
>Unfortunately, the "default environment" in the sense of "core bindings"
definitely is relevant to libraries using `define-module`. For example,
in this module:
```
(define-module (foo)
#:export (foo))
(define foo
(cons 'a 1))
```
at least the bindings for `define`, `cons`, and `quote` are implicitly
imported from `(guile)`.
Yes, that’s why #:pure? #true (IIRC the right keyword argument) should be used.
(+ deprecation warning when #:pure? is absent?)
>R6RS libraries don't have this problem. If instead you write:
```
#!r6rs
(library (foo)
(export foo)
(import (rnrs base))
(define foo
(cons 'a 1)))
```
Here you are demonstrating how R6RS libraries have the _same_ problem. You
should at least have included a version number next to (rnrs base). Who knows,
maybe R8RS will rename ‘cons’ to ‘make-pair’?
As written, it is implicit which version of (rnrs base) is imported (*) – is it
R6RS? Is it R7RS (no, because R7RS uses (scheme ...), but it _could_ have used
(rnrs ...) instead)? A hypothetical future R8RS? (There might be (?) a rule
that if no version is mentioned, the latest version available is used, but
that’s its own source of incompatibilities ...)
(*) no #!r6rs does not count – that’s good for lexical syntax, but the version
number of the _modules_ go into the (import ...). AFAICT, nowhere is the
version number of the (rnrs ...) treated specially w.r.t. #!r6rs.
Compare this with how (implicitly) (guile) is imported – Guile doesn’t know
_which_ version of the (guile) API should be used because it isn’t told (and
currently, there is no option to tell Guile).
That a module is implicitly imported isn’t really a problem, what is the
problem is that the _version_ (in terms of API, not implementation) is implicit.
> the bindings for `define`, `cons`, and `quote` are explicitly imported
from `(rnrs base)`. If the `import` clause were empty, you would get
unbound identifier errors. (The report specifies the meaning of
`library` and its `export` and `import` sub-forms, but it also specifies
that they are not bound by any of the libraries specified by the report,
though `library` is often implemented as a binding in some sort of
implementation-specific start-up environment that is not in scope inside
a library.)
>Similarly, in the Racket module:
```
(module foo racket/base
(provide foo)
(define foo
(cons 'a 1)))
```
>the module's language, `racket/base`, is explicitly the source of the
binding for `provide` as well as those for `define`, `cons`, and
`quote`. If you replaced `racket/base` with `typed/racket/base` or
`lazy`, you would get a valid module with different meanings for those
bindings.
I could be wrong since I don’t the well how Racket is developed, but barring
evidence to the contrary, I’d assume that the bindings in racket/base vary
depending on the version of Racket – just like Guile’s default environment.
Assuming this is true, then Racket has (in terms of implicitness) pretty much
(not exactly, but _pretty much_) the same problem as Guile.
>Of course, you could avoid some indentation by writing the above as:
```
#lang racket/base
(provide foo)
(define foo
(cons 'a 1))
```
Unless the API of racket/base never changes over time: same problem, no version
number or equivalent is included.
>Andy Wingo's "lessons learned from guile, the ancient & spry"
(<https://wingolog.org/archives/2020/02/07/lessons-learned-from-guile-the-ancient-spry>)
concludes in part:
> But as far as next steps in language evolution, I think in the short
> term they are essentially to further enable change while further
> sedimenting good practices into Guile. On the change side, we need
> parallel installability for entire languages. Racket did a great job
> facilitating this with #lang and we should just adopt that.
>
>I agree.
>
> Obviously `#lang` does much more than this (we Racketeers tend to say
`#lang` as shorthand for a bunch of complementary but mostly independent
features), but I think a particularly important aspect is that each
module should explicitly specify its "language"/"default
environment"/"core bindings". If done well, this actually *avoids* the
compatibility concerns some have raised: when you want to make a
breaking change, you pick a new name, and things using the old name keep
working, interoperably.
The thing is, AFAICT using #lang does not imply “explicitly specifying the core
bindings”, as mentioned previously – AFAIK Racket does not pick a new name
every time the list of bindings is changed in some way.
There are benefits to have a standard way to indicate the language of a file
(e.g. #lang) (and I guess if you want to you could define a bunch of fake
languages that also include a couple of imported modules(and which these are
depend on the precise fake language), though I don’t see why not just import
those as modules), but that doesn’t mean we should repeat Racket’s mistakes
with what else (and how) it also uses #lang for.
Best regards,
Maxime Devos
