This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Source for ticket #414

cc

changetime

2012-06-28 10:59:45

component

WG1 - Core

description

Submitter's Name: Jussi Piitulainen

Submitter's Email Address: jpiitula at ling dot helsinki dot fi

Draft Version of Report: 6th

Summary: Internal syntax definitions vs a body with definitions being a letrec*

Full Description:


I desire a clarification on how a body that begins with internal definitions can be equivalent to a `letrec*` when syntax definitions are valid wherever definitions are.

The coverage of the related issues in the report has improved much since I last read it. I'm still not quite satisfied about this particular issue: the report seems to me to be silent, or at best much more implicit than I like, about how a body like the following is equivalent to a `letrec*`. There is no room in a `letrec*` for the syntax definition:


{{{
(lambda () ;say
   (define (f x) ...)   ;the body begins
   (define-syntax ...)
   (f ...))
}}}

If there is a sentence or two that would make the intent of the authors explicit, please add them to the report (in 5.2.2 where the crucial statement of the equivalence is made). Possibly it is something about an "expanded body" not containing the syntax-definitions any more, but I feel like I'm guessing here and looking for some statement that is not there in the report.

I'm concerned because I like the equivalence and wish it to be true.

Relevant sites in the report follow (and a couple of related lesser concerns that turn up when I was investigate this, but it is the issue above that I formally wish to be clarified).


4.2.3 Sequencing (p. 16)

`(begin <expression or definition> ...)` may appear as part of a `<body>`, [...] rationale: [macro output]

5.2 Definitions (p. 23 bottom right)

... valid ... at the _beginning_ of a `<body>`. [my emphasis]

5.2.2 Internal definitions (p. 24 right, mid-section)

An expanded `<body>` containing internal definitions can always be
converted into a completely equivalent `letrec*` expressions.

5.3 Syntax definitions (p. 25 top left)

Syntax definitions are valid wherever definitions are.

7.1.3 Expressions (p. 58 right)

`<body> --> <definition>* <sequence>`

7.1.6 Programs and definitions (p. 60 left)

`<definition> --> ... | <syntax definition> | ...`

Finally, I still have a related concern about `<body>`: the entry on lambda expressions does not tell the truth about `<body>` allowing internal definitions, yet several binding constructs refer to it as being authoritative about `<body>`:

4.1.4 Procedures (p. 12 bottom right)

... `<body>` should be a sequence of one or more expressions.  [this does not allow internal definitions]

4.2.4 Binding constructs (p. 15-16)

... `<body>` should be a sequence of zero or more expressions followed by a sequence of one or more expressions as described in section 4.1.4. ... [this appears in every binding construct and is fine]

Finally finally, "body" is not an index entry (p. 77) and it should be. Probably it should point to 4.1.4 but, as noted above, that site does not tell the truth about `<body>`, or body, and maybe to 5.2.2, where I'm formally seeking clarification. Thank you for your attention.

id

keywords

milestone

owner

cowan

priority

major

reporter

cowan

resolution

fixed

severity

status

closed

summary

Formal Comment: Internal syntax definitions vs a body with definitions being a letrec*

time

2012-06-28 10:33:54

type

defect

Changes

Change at time 2012-06-28 10:59:45

author

cowan

field

comment

newvalue

Formal response sent.

oldvalue

raw-time

1340855985621933

ticket

time

2012-06-28 10:59:45

Change at time 2012-06-28 10:59:45

author

cowan

field

resolution

newvalue

fixed

oldvalue

raw-time

1340855985621933

ticket

time

2012-06-28 10:59:45

Change at time 2012-06-28 10:59:45

author

cowan

field

status

newvalue

closed

oldvalue

accepted

raw-time

1340855985621933

ticket

time

2012-06-28 10:59:45

Change at time 2012-06-28 10:34:09

author

cowan

field

comment

newvalue

oldvalue

raw-time

1340854449977069

ticket

time

2012-06-28 10:34:09

Change at time 2012-06-28 10:34:09

author

cowan

field

owner

newvalue

cowan

oldvalue

alexshinn

raw-time

1340854449977069

ticket

time

2012-06-28 10:34:09

Change at time 2012-06-28 10:34:09

author

cowan

field

status

newvalue

accepted

oldvalue

new

raw-time

1340854449977069

ticket

time

2012-06-28 10:34:09