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 #472
cc
changetime
2012-10-12 06:25:52
component
WG1 - Core
description
In items #91, #148 and #150 we voted to allow the
use of `include`, `include-ci` and `cond-expand`
at the "top-level" respectively, but there remains
some confusion as to their semantics.
Here "top-level" refers to repl and program body
top-levels, but not library bodies.
One interpretation is that these behave like library
declarations, and can expand into `import` forms.
In this case, for a purely static implementation of
R7RS libraries, they must first be statically scanned
from all top-level forms. They cannot be used
outside the top-level, and are not even available
as bindings otherwise. This is the `declaration`
proposal.
Another interpretation is that they are just normal
macros with the obvious definitions (cond-expand
in terms of the output of the `features` procedure),
are available in the `(scheme base)` library, and
consequently can't be used to expand into `import`
since imports have already been resolved. This is
the `syntax` proposal.
Alternately, we could provide `both`. If you think
this is all too confusing you could also vote `remove`,
to drop these extensions.
Related is the matter of whether multiple `import`
forms are allowed in programs or only one may
allowed as in R6RS. With either `syntax` or `remove`
it could make sense to add this restriction, so the
`/single-import` variant is provided.
Note the repl allows allows multiple `import` forms.
id
472
keywords
milestone
owner
cowan
priority
major
reporter
alexshinn
resolution
fixed
severity
status
closed
summary
clarify semantics of non-library library declarations
time
2012-09-11 18:59:51
type
defect
Changes
Change at time 2012-10-12 06:25:52
author
cowan
field
comment
newvalue
oldvalue
4
raw-time
1349997952133930
ticket
472
time
2012-10-12 06:25:52
Change at time 2012-10-12 06:25:52
author
cowan
field
resolution
newvalue
fixed
oldvalue
raw-time
1349997952133930
ticket
472
time
2012-10-12 06:25:52
Change at time 2012-10-12 06:25:52
author
cowan
field
status
newvalue
closed
oldvalue
writing
raw-time
1349997952133930
ticket
472
time
2012-10-12 06:25:52
Change at time 2012-10-04 22:44:00
author
cowan
field
comment
newvalue
oldvalue
3
raw-time
1349365440262418
ticket
472
time
2012-10-04 22:44:00
Change at time 2012-10-04 22:44:00
author
cowan
field
owner
newvalue
cowan
oldvalue
alexshinn
raw-time
1349365440262418
ticket
472
time
2012-10-04 22:44:00
Change at time 2012-10-04 22:44:00
author
cowan
field
status
newvalue
writing
oldvalue
decided
raw-time
1349365440262418
ticket
472
time
2012-10-04 22:44:00
Change at time 2012-10-03 01:01:11
author
cowan
field
comment
newvalue
WG1 voted to accept the `syntax` alternative. As a result, `include`, `include-ci`, and `cond-expand` become normal syntax keywords in the `(scheme base)` library as well as being library declarations. They are no longer special either at the REPL or in top-level programs.
At least the first two cannot be expressed as `syntax-rules` macros using only portable procedures, and so must be described as new primitive expression types in Section 4.1.
oldvalue
2
raw-time
1349200871806490
ticket
472
time
2012-10-03 01:01:11
Change at time 2012-10-03 01:01:11
author
cowan
field
status
newvalue
decided
oldvalue
new
raw-time
1349200871806490
ticket
472
time
2012-10-03 01:01:11
Change at time 2012-09-13 21:13:51
author
alexshinn
field
comment
newvalue
oldvalue
1
raw-time
1347545631351662
ticket
472
time
2012-09-13 21:13:51
Change at time 2012-09-13 21:13:51
author
alexshinn
field
description
newvalue
In items #91, #148 and #150 we voted to allow the
use of `include`, `include-ci` and `cond-expand`
at the "top-level" respectively, but there remains
some confusion as to their semantics.
Here "top-level" refers to repl and program body
top-levels, but not library bodies.
One interpretation is that these behave like library
declarations, and can expand into `import` forms.
In this case, for a purely static implementation of
R7RS libraries, they must first be statically scanned
from all top-level forms. They cannot be used
outside the top-level, and are not even available
as bindings otherwise. This is the `declaration`
proposal.
Another interpretation is that they are just normal
macros with the obvious definitions (cond-expand
in terms of the output of the `features` procedure),
are available in the `(scheme base)` library, and
consequently can't be used to expand into `import`
since imports have already been resolved. This is
the `syntax` proposal.
Alternately, we could provide `both`. If you think
this is all too confusing you could also vote `remove`,
to drop these extensions.
Related is the matter of whether multiple `import`
forms are allowed in programs or only one may
allowed as in R6RS. With either `syntax` or `remove`
it could make sense to add this restriction, so the
`/single-import` variant is provided.
Note the repl allows allows multiple `import` forms.
oldvalue
In items #91, #148 and #150 we voted to allow the
use of `include`, `include-ci` and `cond-expand`
at the "top-level" respectively, but there remains
some confusion as to their semantics.
Here "top-level" refers to repl and program body
top-levels, but not library bodies.
One interpretation is that these behave like library
declarations, and can expand into `import` forms.
In this case, for a purely static implementation of
R7RS libraries, they must first be statically scanned
from all top-level forms. They cannot be used
outside the top-level, and are not even available
as bindings otherwise. This is the `declaration`
proposal.
Another interpretation is that they are just normal
macros with the obvious definitions (cond-expand
in terms of the output of the `features` macro),
are available in the `(scheme base)` library, and
consequently can't be used to expand into `import`
since imports have already been resolved. This is
the `syntax` proposal.
Alternately, we could provide `both`. If you think
this is all too confusing you could also vote `remove`,
to drop these extensions.
Related is the matter of whether multiple `import`
forms are allowed in programs or only one may
allowed as in R6RS. With either `syntax` or `remove`
it could make sense to add this restriction, so the
`/single-import` variant is provided.
Note the repl allows allows multiple `import` forms.
raw-time
1347545631351662
ticket
472
time
2012-09-13 21:13:51