• Home
• All tickets
• All wiki pages

Source for ticket #83

cc

changetime

2012-10-05 06:29:45

component

WG1 - Core

description

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.

id

83

keywords

keyword,auxilary

milestone

owner

alexshinn

priority

major

reporter

arcfide

resolution

fixed

severity

status

closed

summary

Auxiliary Keywords

time

2010-10-16 00:12:57

type

task

Changes

Change at time 2012-10-05 06:29:45

author

cowan

field

comment

newvalue

oldvalue

6

raw-time

1349393385994109

ticket

83

time

2012-10-05 06:29:45

Change at time 2012-10-05 06:29:45

author

cowan

field

resolution

newvalue

fixed

oldvalue

raw-time

1349393385994109

ticket

83

time

2012-10-05 06:29:45

Change at time 2012-10-05 06:29:45

author

cowan

field

status

newvalue

closed

oldvalue

writing

raw-time

1349393385994109

ticket

83

time

2012-10-05 06:29:45

Change at time 2011-07-18 17:27:21

author

alexshinn

field

comment

newvalue

oldvalue

5

raw-time

1310984841000000

ticket

83

time

2011-07-18 17:27:21

Change at time 2011-07-18 17:27:21

author

alexshinn

field

status

newvalue

writing

oldvalue

decided

raw-time

1310984841000000

ticket

83

time

2011-07-18 17:27:21

Change at time 2011-07-10 18:28:58

author

alexshinn

field

comment

newvalue

We voted to make these bound.

oldvalue

4

raw-time

1310297338000000

ticket

83

time

2011-07-10 18:28:58

Change at time 2011-07-10 18:28:58

author

alexshinn

field

status

newvalue

decided

oldvalue

reopened

raw-time

1310297338000000

ticket

83

time

2011-07-10 18:28:58

Change at time 2011-05-19 15:40:52

author

alexshinn

field

comment

newvalue

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

oldvalue

3

raw-time

1305794452000000

ticket

83

time

2011-05-19 15:40:52

Change at time 2011-05-19 15:40:52

author

alexshinn

field

resolution

newvalue

oldvalue

fixed

raw-time

1305794452000000

ticket

83

time

2011-05-19 15:40:52

Change at time 2011-05-19 15:40:52

author

alexshinn

field

status

newvalue

reopened

oldvalue

closed

raw-time

1305794452000000

ticket

83

time

2011-05-19 15:40:52

Change at time 2011-01-24 06:51:29

author

cowan

field

comment

newvalue

WG1 voted to leave them unbound.

oldvalue

2

raw-time

1295823089000000

ticket

83

time

2011-01-24 06:51:29

Change at time 2011-01-24 06:51:29

author

cowan

field

resolution

newvalue

fixed

oldvalue

raw-time

1295823089000000

ticket

83

time

2011-01-24 06:51:29

Change at time 2011-01-24 06:51:29

author

cowan

field

status

newvalue

closed

oldvalue

new

raw-time

1295823089000000

ticket

83

time

2011-01-24 06:51:29

Change at time 2010-10-16 02:33:25

author

cowan

field

comment

newvalue

oldvalue

1

raw-time

1287171205000000

ticket

83

time

2010-10-16 02:33:25

Change at time 2010-10-16 02:33:25

author

cowan

field

summary

newvalue

Auxiliary Keywords

oldvalue

Auxilary Keywords

raw-time

1287171205000000

ticket

83

time

2010-10-16 02:33:25

Change at time 2010-10-16 02:33:25

author

cowan

field

description

newvalue

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.

oldvalue

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

raw-time

1287171205000000

ticket

83

time

2010-10-16 02:33:25