Am Fr., 25. Sept. 2020 um 04:38 Uhr schrieb Jim Rees <xxxxxx@gmail.com>:
>
> Thanks for clearing up my last question.    I finished coding up the changes & tests for the un-definition case today.
>
> The specification touches on the parallels between definitions and aliases, but doesn't mention a prohibition against using alias to bind an id that is already bound in the current body, or imported by the current top-level library/program body.    Do you think it's necessary to state that, or should it be obvious?

Yes, in both cases, it is assumed to be an error. I can explicitly
state this in the document. Of course, an implementation is free to
allow it nonetheless.

> The spec says "The alias definition is used to transfer the binding of one identifier to another".   The word transfer really implies that something is moved from one place to another, and is therefore no longer in the original place.   Maybe copy would be a better term?

After some pondering, I took the wording from Chez's documentation. I
am not a native speaker so some nuances of wording are lost to me. I
understand the issue with "transfer". "Copy", however, may not be
better because it may imply that something is actually being
duplicated. More detailed would be: "It is arranged that <id1> shares
the binding of <id2>" or something like it. What do you think?

> splicing-let-alias ?       Just a thought.   I have it in my system, and it has some use cases, but none that couldn't be effectively replaced with splicing-let-syntax.

Then we would also want a mixture, a splicing binding construct that
can contain either aliases or syntax definitions... I think this
should be solved in a more universal manner. Chez's modules (lexically
local libraries) solve this problem elegantly, for example. That
universal construction may then be used to implement
splicing-let-alias as a derived form.

(When I have time, I may add modules to Unsyntax and document them in
a SRFI for standardization and to encourage implementers to add them
as well.)