RE: The Guile junk drawer and a C plea

[Maxime Devos]

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