[Addressing the SRFI 206 mailing list as well.]

Am So., 16. Aug. 2020 um 00:56 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Fri, Aug 14, 2020 at 10:30 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> PS One more argument for "define-auxiliary-syntax" is that it is the
>> more primitive construct vs. the magic module.
>
>
> Any sufficiently advanced technology is indistinguishable from magic.

Magic in the sense that the (srfi 206 *) module is (yet) the only
module, which does not export a finite list of identifiers.

> I disagree with your perception of the (auto) module being more "magic"
> than your binding manipulation primitives.  (auto) is actually more
> natural and easier to implement if you have a module meta language
> like Chibi or Scheme48.

Not all Schemes have a module meta language. For some Schemes, (srfi
206 *) may be easier to implement, for others (srfi 206).

> Treating "bindings" as first class and providing primitives to manipulate
> them feels more magical to me.  I'm not sure the Chibi implementation
> is correct, and have doubts about the general portability of the idea.

The Chibi implementation is far from fully tested; it is so far a
two-hour work to provide proof of concept.

That said, I don't understand what you mean by treating "bindings" as
first-class in this context? "define-auxiliary-syntax" is no primitive
to manipulate bindings. The variable names a location and a keyword
names a type of syntax. "define-auxiliary-syntax" just binds an
identifier so that it names a type of syntax, which is possibly named
by other identifiers as well.

But this is absolutely nothing new in R7RS:

(import (scheme base) (rename (scheme base) (+ plus))

In the lexical environment resulting from this import declaration,
both "+" and "plus" name the same location.

> In particular, you're relying on managing these first class bindings via
> a hash-table at compile time, which leads me to wonder how this
> would work with separate compilation?

I think this is unrelated to whether these auxiliary syntax bindings
are introduced through (srfi 206 *) or through explicit uses of
"define-auxiliary-syntax". The only bindings that are relevant for
separate compilation are module top-level bindings and for these,
(srfi 206 *) and define-auxiliary-syntax are equipotent. In any case,
making it work with separate compilation is easy. Just to have
something concrete, let's take the model from
https://legacy.cs.indiana.edu/~dyb/pubs/implicit-phasing.pdf, which
also underlies Chez and psyntax. Here, during expansion type, every
(top-level) identifier is mapped to a unique label, where the
uniqueness is maintained across separately compiled modules. When such
a compiled module is visited or invoked, a table mapping labels to
bindings (locations or types of syntax) is created on the fly. So all
that has to be done is to add a new type of label (which maps 1:1 to
symbols), which corresponds to auxiliary syntax keywords created
through the import from (srfi 206 *) or through
define-auxiliary-syntax.

I will add another proof of concept for separate compilation.

Besides, as I have mentioned before, Chez Scheme, which has separate
compilation, already has the "alias" binding construct, which creates
aliases (two or more identifiers naming the same location or type of
syntax) in the above sense.

Marc