Opened 6 years ago

Closed 4 years ago

#83 closed task (fixed)

Auxiliary Keywords

Reported by: arcfide Owned by: alexshinn
Priority: major Milestone:
Component: WG1 - Core Keywords: keyword,auxilary

Description (last modified by cowan)

R6RS and R5RS have different behaviors for auxiliary keywords. Do we use symbolic keywords as in R5RS or do we use auxiliary keywords identifiers and implicit keywords as in R6RS?

Syntaxes like COND and CASE
have what are called auxiliary keywords, or auxiliary syntax. TSPL4 calles
them keywords, R6RS calls them a combination of literal identifiers and
auxiliary syntax depending on what the context of the discussion is. In
terms of SYNTAX-RULES, the form has something like this syntax:

(syntax-rules (<literal> ...) <clause> <clause> ...)

Now, in the above, the literals are auxiliary syntax keywords. The rules
for matching literals in a SYNTAX pattern are as follows, quoted from
the R6RS document:

A literal identifier matches an input subform if and only if the
input subform is an identifier and either both its occurrence in
the input expression and its occurrence in the list of literals
have the same lexical binding, or the two identifiers have the
same name and both have no lexical binding.

Now, the TSPL4 has some more to say about this:

Literals serve as auxiliary keywords, such as else in case and
cond expressions.


An input form F matches a pattern P if and only if [...] P is a
literal identifier and F is an identifier with the same binding
as determined by the predicate free-identifier=?.

This is further described in Section 8.3.

free-identifier=? is used to determine whether two identifiers
would be equivalent if they were to appear as free identifiers
in the output of a transformer. Because identifier references
are lexically scoped, this means (free-identifier=? id1 id2)
is true if and only if the identifiers id1 and id2 refer
to the same binding. (For this comparison, two like-named
identifiers are assumed to have the same binding if neither is
bound.) Literal identifiers (auxiliary keywords) appearing in
syntax-case patterns (such as else in case and cond) are matched
with free-identifier=?.

R6RS further goes on to export, explicitly, the auxilary keywords ELSE
and others. This gives some benefits which are actually quite nice in
some cases. What this permits is for you to have a number of additiona
bindings for that auxiliary keyword, and it also allows you to use
keywords internally that are not visible outside of a module or library
form. In general, I'm in favor of this form, having used it a bit.

What isn't as fortunate, or what some people don't like, is that it
makes the forms of COND and CASE, for example, sensitive to to their
lexical environments. So, something like this isn't going to work in
the way that some people expect:

(let ([else #f])

(cond [else 'a]))

This will actually evaluate to an unspecified value, because the else
there is not the same else as what COND expects. In something like R5RS,
this could have returned 'a.

One place where you can use this is if you want to use a different word
for else. You can name it to the Chinese word for else, if you so feel
like it.

The ticket is basically, do we use the lexical keywords, or symbolic
ones? My vote is for the lexical ones.

Change History (6)

comment:1 Changed 6 years ago by cowan

  • Description modified (diff)
  • Summary changed from Auxilary Keywords to Auxiliary Keywords

comment:2 Changed 6 years ago by cowan

  • Resolution set to fixed
  • Status changed from new to closed

WG1 voted to leave them unbound.

comment:3 Changed 6 years ago by alexshinn

  • Resolution fixed deleted
  • Status changed from closed to reopened

Many new issues pertaining to this ticket have been
brought up on the public discussion list, so we are

comment:4 Changed 6 years ago by alexshinn

  • Status changed from reopened to decided

We voted to make these bound.

comment:5 Changed 6 years ago by alexshinn

  • Status changed from decided to writing

comment:6 Changed 4 years ago by cowan

  • Resolution set to fixed
  • Status changed from writing to closed
Note: See TracTickets for help on using tickets.