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.

Ticket 472: clarify semantics of non-library library declarations

2012-10-12 06:25:52
WG1 - Core
cowan
major
alexshinn
fixed
source
closed
2012-09-11 18:59:51
defect

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.

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

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.

owneralexshinncowan
statusdecidedwriting
resolutionfixed
statuswritingclosed