On Mon, 18 Apr 2011, Alex Shinn wrote:
> On Sun, Apr 17, 2011 at 11:00 AM, Andre van Tonder <andre@het.brown.edu> wrote:
>> On Sun, 17 Apr 2011, Alex Shinn wrote:
>>
>>> Then I realized you're assuming that any imported
>>> binding from another module should count as having
>>> the "same lexical binding," not simply be bound to
>>> the same value, in which case they would match.
>>>
>>> The module system does not make this requirement,
>>> in deference to the many types of module systems
>>> out there which may simply copy the bindings, so in
>>> general you can't assume you can rename =>.
>>
>> I don't understand what you mean. I want => to be bound (to a macro that
>> expands to an error message). So it does have a specific binding in the
>> exporting module, and can therefore be renamed, excluded, translated into
>> another language, etc. This should work in any module system that allows
>> exporting and renaming identifiers, shouldn't it?
>
> The exact rules of the syntax-rules pattern language are:
>
> [...] A subform in the input matches a literal
> identifier if and only if it is an identifier and either both its
> occurrence in the macro expression and its occurrence in
> the macro definition have the same lexical binding, or the
> two identifiers are equal and both have no lexical binding.
>
> In R5RS there was no ambiguity. In the presence of a module
> system, the question arises whether an import creates a new
> lexical binding or not. For example, if import is a macro which
> basically expands into:
>
> (define <imported-variable>
> (%module-ref <module> '<imported-variable))
>
> then it's clearly a new binding, and won't match. Currently,
> the standard does not explicitly forbid this approach,
I am not sure you have thought this through. Making new bindings
for imports as in your example would, among other problems, break lexical
scoping of procedures and macros in the exporting library that
refer to other bindings in the exporting library.
It is best to think of importing as importing lexical environments,
not making new bindings.
> which
> means you can't rely on being able to rename literal identifiers
> like "else" and "=>".
If they are bindings as in R6RS, of course you can rename them.
>>>> - We cannot easily create a teaching language where => clauses are not
>>>> allowed in COND unless => is bound.
>>>
>>> Sure you can, just bind =>.
>>
>> It is not the same. For example, I may want COND without =>,
>> AND I may want => to be free so that my users can do with it
>> what they want. For your solution to work, the user of your
>> little language will have to import both COND and => from your
>> library just to obtain a simpler =>-less COND, and then
>> depending on the module system they may be prevented from
>> redefining => for their own purposes.
>
> Again, if we can't rename these identifiers you can't
> redefine => for your own purposes anyway.
I said I wanted to EXCLUDE =>, not rename or redefine it. I don't
think you understood what I wrote.
You are the one who wants to bind => for your own purposes in this
example, not me.
>>> There is no free-identifier=? in WG1 Scheme, nor at the present
>>> time is there likely to be in WG2 Scheme.
>>
>> There has to be something like that in the machinery of the macro system,
>> because this is the comparison operation Scheme uses to identify the meaning
>> of ANY lexical binding.
>
> In the old Kohlbecker coloring algorithm there was no distinction
> of whether the identifiers were bound or not.
The Kohlbecker algorithm is unsuitable for modules.
> In an explicit renaming macro system, you just have a comparator
> function passed as a parameter to the macro expander, and this
> also doesn't need to know if the identifiers are bound.
> The syntactic-closures equivalent is
>
> (identifier=? id1 env1 id2 env2)
>
> which works whether the identifiers are bound or not.
AS I SAID,
There has to be something like free-identifier=? in the machinery of the
macro system,
because this is the comparison operation Scheme uses to identify the meaning
of ANY lexical binding.
You first contradict me and then you give me examples of exactly what
I said, the equivalent comparator to free-identifier=? in two other
macro systems.
> WG2 is planning on adding ER macros because they are a
> lowest common denominator of low-level hygienic macro systems.
> They're easy to implement in any other macro system.
Yes, and everything I said can be implemented in the explicit renaming
macro system. The ER system has environments associating identifiers
to bindings, these environments can be exported from and imported into
modules, imports can easily be renamed or excluded, and so on.
In summation, nothing that you have said prevents literals like
UNQUOTE, underscore, =>, etc., from being bound, and then having all
the advantages of translation, exclusion, etc.
