Between R4RS and R5RS, various portions of the standards changed to
favor a state where there are no reserved identifiers. Specifically,
section 2.1 (Lexical Identifiers) changed from including:
"* Certain identifiers are reserved for use as syntactic keywords (see
below).
* Any identifier that is not a syntactic keyword may be used as
variable (see section see section 3.1 Variables and regions)."
in R4RS to:
"* Any identifier may be used as a variable or as a syntactic keyword
(see sections see section 3.1 Variables; syntactic keywords; and regions
and see section 4.3 Macros)."
in R5RS. Section 3.1 changed from reading:
"Any identifier that is not a syntactic keyword (see section see section
2.1 Identifiers) may be used as a variable. A variable may name a
location where a value can be stored. A variable that does so is said to
be bound to the location"
in R4RS to:
"An identifier may name a type of syntax, or it may name a location
where a value can be stored. An identifier that names a type of syntax
is called a syntactic keyword and is said to be bound to that syntax. An
identifier that names a location is called a variable and is said to be
bound to that location."
According to the (deprecated) R4RS sense, the following expressions are
illegal, but not so in R5RS:
(define set! 3)
(set! begin list)
However, amidst this change, the lexical structure (section 7.1.1) was
unchanged. The R5RS lexical structure has the following productions:
<formals> --> (<variable>*) | <variable>
| (<variable>+ . <variable>)
<assignment> --> (set! <variable> <expression>)
<definition> --> (define <variable> <expression>)
| (define (<variable> <def formals>) <body>)
| (begin <definition>*)
<def formals> --> <variable>*
| <variable>* . <variable>
..all of which allow <variable> as the left-hand-side/formal parameter.
<variable>, as in R4RS, is defined as:
<variable> => <'any <identifier> that isn't
also a <syntactic keyword>>
<syntactic keyword> --> <expression keyword>
| else | => | define
| unquote | unquote-splicing
<expression keyword> --> quote | lambda | if
| set! | begin | cond | and | or | case
| let | let* | letrec | do | delay
| quasiquote
This, contrary to the body of the report, indicates that the
primitive-naming identifiers and syntactic keywords are illegal as
left-hand-sides/formal parameters, rendering the above expressions
syntax errors. Can anyone explain the inconsistency?
Scott
> This, contrary to the body of the report, indicates that the
> primitive-naming identifiers and syntactic keywords are illegal as
> left-hand-sides/formal parameters, rendering the above expressions
> syntax errors. Can anyone explain the inconsistency?
Just a lazy mistake, I think. The grammar didn't get properly
updated, it looks like.
If any of the R5RS authors are reading this, could they please
confirm/deny this?
I find it hard to believe that this hasn't been spotted before. It's
quite a big compatibility issue and has huge implications for things
like macros. I'd be interested to hear from implementors that claim /
strive for R5RS compliance what model their implementations follow.
Matthias
MR> Thomas Bushnell, BSG wrote:
>> "Scott G. Miller" <scgm...@freenetproject.org> writes:
MR> >
MR> >>This, contrary to the body of the report, indicates that the
MR> >>primitive-naming identifiers and syntactic keywords are illegal as
MR> >>left-hand-sides/formal parameters, rendering the above expressions
MR> >>syntax errors. Can anyone explain the inconsistency?
>> Just a lazy mistake, I think. The grammar didn't get properly
>> updated, it looks like.
MR> >
MR> If any of the R5RS authors are reading this, could they please
MR> confirm/deny this?
MR> I find it hard to believe that this hasn't been spotted before. It's
MR> quite a big compatibility issue and has huge implications for things
MR> like macros. I'd be interested to hear from implementors that claim /
MR> strive for R5RS compliance what model their implementations follow.
It's long been spotted: The published version of R5RS (in HOSC) has a
note confirming there are no reserved words.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
> MR> >
>
> MR> If any of the R5RS authors are reading this, could they please
> MR> confirm/deny this?
>
> MR> I find it hard to believe that this hasn't been spotted before. It's
> MR> quite a big compatibility issue and has huge implications for things
> MR> like macros. I'd be interested to hear from implementors that claim /
> MR> strive for R5RS compliance what model their implementations follow.
>
> It's long been spotted: The published version of R5RS (in HOSC) has a
> note confirming there are no reserved words.
>
I'm assuming your referring to the Notes section. This notes
differences between R4 and R5RS, and indicates that there are no
reserved identifiers, which still does not clarify the issue at hand.
Furthermore, (unless we have an author present that can straighten this
out), this is merely another section that was updated from 4 to 5, while
the Lexical Structure wasn't.
Scott
> I'm assuming your referring to the Notes section. This notes
> differences between R4 and R5RS, and indicates that there are no
> reserved identifiers, which still does not clarify the issue at
> hand.
I'm confused. I thought that was the issue at hand, i.e. whether any
identifier may be used as a variable or if some are reserved.
I agree that r5rs is self-contradictory on this point. The section on
identifiers says "any identifier may be used as a variable or as a
syntactic keyword", and the language changes section says "there are
no reserved identifiers", but the formal syntax says a variable may
only be an "<identifier> that isn't also a <syntactic keyword>".
So there are two possibilites:
1. The authors forgot to update the formal syntax.
2. The authors accidentally added a statement that any identifier
may be used as a variable, and accidentally added an explicit
statement that they were making this change. They also
accidentally removed two of the statements that said that some
identifiers could not be used as variables.
The odds of possibility 2 seem so remote that I don't understand why
you are seriously entertaining it.
-al
I agree that its highly unlikely to be the latter case, I'm just
surprised that the more formal definition of the language was neglected
infavor of the informal text.
Scott
I also want to add that this has serious implications for compiler
writers, as if the lexical structure was correct (which it probably
isn't) then an optimizer would have a much easier time of things, since
it could quite trivially detect the redefinition of procedures on which
its making optimization assumptions.
Scott
As Scott already mentioned, it would seem to be a rather huge and
fundamental oversight, particularly as the lexical structure *did* get
updated between R4RS and R5RS, e.g. <macro use> and <macro block> were
added and <derived expression> was "informalized". So it's not the case
that the R5RS authors simply forgot about the lexical structure section
altogether.
I, like everyone else who has posted in this thread so far, too am
inclined to believe in version 1 of events, but since it is such a
fundamental issue I would really appreciate a confirmation of this by
the R5RS authors.
Matthias
> it would seem to be a rather huge and fundamental oversight
Jeez, it's one stinkin' line in a fifty-page document.
One reason that things get described in more than one place in r5rs is
to make the intent discernible even if there are isolated mistakes.
-al
No, he is referring to the 'Clarifications and Corrections' section
on page 105 of the published version of R5RS, which Kluwer has kindly
made available as a pdf file at:
http://www.brics.dk/~hosc/11-1/168705.html
It states that Section 3.1 takes precedence in this instance. There
are no reserved words in R5RS Scheme.
-Richard Kelsey
> No, he is referring to the 'Clarifications and Corrections' section on
> page 105 of the published version of R5RS, which Kluwer has kindly made
> available as a pdf file at:
>
> http://www.brics.dk/~hosc/11-1/168705.html
>
> It states that Section 3.1 takes precedence in this instance. There are
> no reserved words in R5RS Scheme.
> -Richard Kelsey
The chapter numbers have shifted!! So by Section 3.1 of course it means
what we all know as Section 2.1.
-John
> he is referring to the 'Clarifications and Corrections' section on
> page 105 of the published version of R5RS, which Kluwer has kindly
> made available as a pdf file at:
>
> http://www.brics.dk/~hosc/11-1/168705.html
Thanks. I didn't realize that was available.
For those who just want to read the last page, here it is, courtesy of
pdftotext:
[As John Tobey pointed out, the section numbers are one off from the
free version, e.g. section 8.2 below == section 7.2 in the "standard
version" of the standard.]
Clarifications and corrections
Several inconsistencies in this report have been pointed out since
its initial publication on the World-Wide Web. This section
addresses the most important of them.
Semantics of call-with-current-continuation
The definition of call-with-current-continuation in Section 8.2 is
incorrect because it is incompatible with dynamic-wind. As shown
in Section 4 of [1], however, this incorrect semantics is adequate
to define the shift and reset operators, which can then be used to
define the correct semantics of both dynamic-wind and
call-with-current-continuation.
Redefinition of keywords
As stated in Section 3.1, keywords are not reserved. The grammar
specified in Section 8.1 is thus somewhat misleading because a
program may redefine any or all syntactic keywords. In
particular, it is possible to use any identifier as a variable.
Port?
Section 4.2 includes port? in the list of predicates defining
disjoint types; there is no such procedure. Input-port? and
output-port? should be included in this list of predicates. An
object may satisfy both input-port? and output-port?, but cannot
satisfy any other pair of predicates in this list.
References
1. Filinski, Andrzej. Representing Monads. In Proceedings of the
1994 ACM SIGPLAN-SIGACT Symposium on Principles of Programming
Languages, pp. 446457.