On Thu, Aug 25, 2011 at 3:02 AM, John Cowan <[email protected]> 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
