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