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 wiki WG1BallotCowan version 63

author

cowan

comment

ipnr

198.185.18.207

name

WG1BallotCowan

readonly

text

= Instructions =

* You may list as many of the options as you want in order of preference.
* Options are comma-delimited (ignoring space) and case-insensitive.
* You can pipe-delimit (|) options you want to give equal weight to.
* You may write in your own option if you announce it to the list first.
* You may specify a variant with option/variant, for example srfi-1/module to vote for srfi-1 but clarify it should be in a separate module. Please also include the srfi-1 option in this case.
* You can write a free-form rationale after the "preferences" line,
* module means "yes, but I want it in a separate module",
* wg2 means "no, but I think it should go in WG2".
* undecided means I want to discuss this issue further.
* Abstain on any item by leaving the preferences blank.

= WG1 Ballot Items To Finalize By Sep. 18 =

== WG1 - Core ==

=== #121 The semantics of expt for zero bases has been refined ===

The R5RS definition of expt is:

{{{
-- procedure: expt z1 z2
Returns Z1 raised to the power Z2. For z_1 ~= 0

z_1^z_2 = e^z_2 log z_1

0^z is 1 if z = 0 and 0 otherwise.
}}}

however exponents with negative real parts are undefined.
R6RS attempted to clarify this with:

{{{
0.0^z is 1.0 if z = 0.0, and 0.0 if (real-part z) is positive.
For other cases in which the first argument is zero, either
an error is signalled or an unspecified number is returned.
}}}

(Ignore the change in exactness, which was strictly editorial
and the examples clarify that the rules ignore exactness.)

This is unique in all the reports of a result either
signalling an error or returning a value. The motivation
for this was because R6RS consistently removed uses of the
"is an error" terminology which would more naturally fit
this situation.

An alternative, `r5rs-error`, is to restore the "is an error"
text since we are not avoiding this in R7RS:

{{{
0.0^z is 1.0 if z = 0.0, and 0.0 if (real-part z) is positive.
It is an error for the first argument to be zero in other cases.

}}}

* '''Options:''' r5rs, r5rs-error, r6rs, undecided
* '''Default:''' r6rs
* '''Preferences:''' r5rs-error, r5rs
* '''Rationale:''' I agree that the R6RS rule makes no sense in an R7RS context. However, it's worth saying explicitly that the oddball zero cases are errors.

=== #472 clarify semantics of non-library library declarations ===

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.

* '''Options:''' declaration, syntax, both, remove
* '''Default:'''
* '''Preferences:''' declaration, both, syntax, remove
* '''Rationale:''' `Declaration` is the option that makes sense to me, ''without'' however permitting declarations in included files (they are currently forbidden). I see no reason in these cases to make a distinction between library bodies on the one hand and programs and REPLs on the other. The `syntax` option allows them to be used in random nested places, which I consider to be unnecessary.

=== #473 library declaration locations in top-level ===

R6RS allows only a single library declaration, `import`,
at the beginning of a program body, and this must
contain all imported libraries.

Pending the result of ticket #472 we may also allow
`include(-ci)` and `cond-expand` to expand into
imports, and so the single form restriction would not
make sense. However, it would be reasonable to
restrict all library declarations to the beginning of
a program - the first non-declaration would begin
the real body. This is the `beginning-only` option.

The advantage of the `r6rs` proposal is that it would
not require any changes in existing R6RS program
loading implementations to support. If the result of
ticket #472 indicates multiple declaration types are
available this option would automatically become
invalid, so you don't need to vote against it on those
grounds.

The advantage of the `beginning-only` option is
that it becomes possible to statically determine
all program imports without expansion, which was
the primary motivation of a static library system.

The final alternative is `any-top-level`, which
allows these forms anywhere at the top-level,
possibly interspersed with definitions. The advantage
of this is that you can cut&paste repl sessions
(for which interspersed imports are always allowed)
as a program. The disadvantage is that programs
can no longer be resolved separately from expansion.

* '''Options:''' r6rs, beginning-only, any-top-level
* '''Default:'''
* '''Preferences:''' beginning-only, any-top-level, r6rs
* '''Rationale:''' Note that this is about programs only, not REPLs or library bodies. I really, really dislike both `any-top-level` and `beginning-only`. The first is too flexible, the second, not flexible enough. Very reluctantly I choose `beginning-only` because it preserves static analysis. I see no benefit to the `r6rs` option at all, given that R6RS systems will have to provide additional support for R7RS library syntax anyway.

time

2012-09-19 10:34:03