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. For other cases in which the first argument is zero, either an error is signalled or an unspecified number is returned.Rationale: I'm voting r5rs until this ballot item is fixed, which I believe means changing the language associated with r5rs-error to say "it is an error." If that change is made, I'll put r5rs-error first.
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.
Rationale: There's just too much confusion in this area.
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.