Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

<variable> inconsistency in R5RS

10 views
Skip to first unread message

Scott G. Miller

unread,
Jul 23, 2002, 2:58:24 PM7/23/02
to
It seems there is some ambiguity in the standard with respect
to legal identifiers for assignments, definitions, and formal
parameters.

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

Thomas Bushnell, BSG

unread,
Jul 23, 2002, 5:41:41 PM7/23/02
to
"Scott G. Miller" <scgm...@freenetproject.org> writes:

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


Matthias Radestock

unread,
Jul 25, 2002, 2:02:25 AM7/25/02
to

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

Michael Sperber [Mr. Preprocessor]

unread,
Jul 25, 2002, 3:55:21 AM7/25/02
to Matthias Radestock
>>>>> "MR" == Matthias Radestock <matt...@sorted.org> writes:

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

Scott G. Miller

unread,
Jul 25, 2002, 5:55:54 PM7/25/02
to
Michael Sperber [Mr. Preprocessor] wrote:

> 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


Al Petrofsky

unread,
Jul 25, 2002, 6:37:18 PM7/25/02
to
"Scott G. Miller" <scgm...@freenetproject.org> writes:

> 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

Scott G. Miller

unread,
Jul 25, 2002, 6:46:48 PM7/25/02
to
Al Petrofsky wrote:
e 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

Scott G. Miller

unread,
Jul 25, 2002, 6:48:40 PM7/25/02
to
Scott G. Miller wrote:

> Al Petrofsky wrote:
>
> 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

Matthias Radestock

unread,
Jul 25, 2002, 8:07:06 PM7/25/02
to
Al Petrofsky wrote:
>
> 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.
>

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

Al Petrofsky

unread,
Jul 26, 2002, 12:16:21 AM7/26/02
to
Matthias Radestock <matt...@sorted.org> writes:

> 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

Richard Kelsey

unread,
Jul 26, 2002, 2:38:05 PM7/26/02
to
"Scott G. Miller" <scgm...@freenetproject.org> wrote in message news:<Kt_%8.3937$eb....@nwrddc04.gnilink.net>...

> Michael Sperber [Mr. Preprocessor] wrote:
> > 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.

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

John Tobey

unread,
Jul 26, 2002, 9:10:21 PM7/26/02
to
On Fri, 26 Jul 2002 14:38:05 -0400, Richard Kelsey wrote:

> 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

Al Petrofsky

unread,
Jul 26, 2002, 10:22:49 PM7/26/02
to
kel...@s48.org (Richard Kelsey) writes:

> 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. 446­457.

0 new messages