#lang header

[Lassi Kortela]

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.