Thank you for keeping an open line of communication between Racket and
Scheme.
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.
I wrote some thoughts about how Guile could gradually adopt `#lang` in a
way that would provide for future compatibility in a sub-thread on this
list last year: https://lists.gnu.org/r/guile-devel/2023-02/msg00075.html
The fundamental problem with #lang is that it comes from the language
implementation (Racket), not from language specifications (e.g. R6RS or
the Python Language Reference). You explain its other virtues well, but
this problem is insurmountable.
#lang would only be a good idea if the established programming languages
all agreed to it. When they don't, source files with #lang are limited
to Racket. I agree that a source file should identify its own language,
but the wider "ecosystem" will not get there in decades. If we tell
languages what to do, we'll be stuck with unpopular languages.
Think about it: What would happen if one C compiler decided that all
source files have to start with "#lang C" or "#lang C++"?
My long-term pipe dream (though I have no particular plans to work on
it), inspired by conversations with Christine, would be a grand,
interoperable unification of Guile and Racket based on `#lang` and
linklets:
https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00010.html and,
earlier,
https://lists.gnu.org/archive/html/guix-devel/2021-08/msg00099.html
I'm sympathetic to thinking in this general direction.
