On Thu, Aug 25, 2011 at 3:02 AM, John Cowan <cowan@mercury.ccil.org> wrote:
>
> 1) In delay and force, the effect of the expression returning other than
> one value is unspecified.
[...]
> 3) The effect of passing other than one value to a continuation (modulo
> the defined cases) is unspecified.

The costs of detecting these cases in many implementation
strategies is prohibitively high.  We could change this to say
"is an error" but that's really the same thing, and in particular
a likely extension to MVs is the CL semantics where
unexpected values are silently ignored.

> 2) Altering a top-level binding not introduced by a definition has an
> unspecified effect on the behavior of built-in procedures (which in
> practice amounts to an unspecified effect, period).

With the introduction of a module system I think it no
longer makes sense to have this restriction, we should
remove it.

Note that the mutation would only be allowed at the
top-level (repls and programs), since mutating imports
in modules is explicitly an error.

> 4) The effect of using a captured continuation to enter or exit the
> "before" and "after" thunks of dynamic-wind is unspecified.

I need to look into this more, it's a complex issue.

> 5) The effecdt of using eval to assign a variable bound in the
> scheme-report-environment is unspecified.

I don't think we can do more than to say this is an
error.  The spirit of (scheme-report-environment) is that
it's immutable.

> 6) The effect of opening for output a file that already exists is
> unspecified.

As you say, this is on the ballot and should be specified.

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports