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, which
means you can't rely on being able to rename literal identifiers
like "else" and "=>".

>>> - 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.

>> 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.

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.

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.

>>> - Typically, such literals mcan be bound to a macro expanding to a syntax
>>> error, which is extremely useful for error checking.
>>
>> If they are unbound we also get a descriptive error.
>
> No you would not always.  As an example, consider what happens if a user
> binds UNQUOTE in his code.  Suddenly a quaisquote expression that used to
> work may now have (UNQUOTE ...) subexpressions left over.  If UNQUOTE is
> bound to an error message macro, this problem will throw an error at
> expansion time.  IF not, you will have to wait until runtime and then get a
> generic unbound identifier error instead.

Most Schemes I've seen with any kind of half decent analysis
will warn about unbound identifiers, and since we won't have
identifier syntax your argument only applies to keywords in the
operator position.

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports