Opened 5 years ago

Closed 5 years ago

#472 closed defect (fixed)

clarify semantics of non-library library declarations

Reported by: alexshinn Owned by: cowan
Priority: major Milestone:
Component: WG1 - Core Keywords:
Cc:

Description (last modified by alexshinn)

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.

Change History (4)

comment:1 Changed 5 years ago by alexshinn

  • Description modified (diff)

comment:2 Changed 5 years ago by cowan

  • Status changed from new to decided

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.

comment:3 Changed 5 years ago by cowan

  • Owner changed from alexshinn to cowan
  • Status changed from decided to writing

comment:4 Changed 5 years ago by cowan

  • Resolution set to fixed
  • Status changed from writing to closed
Note: See TracTickets for help on using tickets.