On the scheme-implementors list, Jonathan Shapiro raised the issue of undefined behavior in the standard, which he feels is a Bad Thing in a language that purports to have a formal model. In general, I'm inclined to agree, so I looked through the current draft for references to "unspecified" and "undefined" (some of which I changed to "unspecified"). I ignored references to returning an unspecified value and to doing things in an unspecified order, since these do not induce wide-open semantic failure in which anything could happen. Here's what I've found (and marked in the source with \todo comments):
1) In delay and force, the effect of the expression returning other than one value is unspecified. 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). 3) The effect of passing other than one value to a continuation (modulo the defined cases) is unspecified. 4) The effect of using a captured continuation to enter or exit the "before" and "after" thunks of dynamic-wind is unspecified. 5) The effecdt of using eval to assign a variable bound in the scheme-report-environment is unspecified. 6) The effect of opening for output a file that already exists is unspecified. There is a ballot item to standardize #6 to truncate the file, but this may not fly, as several existing implementations throw an error instead. Nevertheless, it does not seem to me that all-out undefined behavior is justified here: some language like "an error may be signalled, or the implementation may perform an unspecified action on the file (such as truncating it) and then open it" seems to me to be sufficient. Does anyone seem more cases of unspecified effects? What are suitable low-impact ways to remove them? -- Babies are born as a result of the John Cowan mating between men and women, and most http://www.ccil.org/~cowan men and women enjoy mating. [email protected] --Isaac Asimov in Earth: Our Crowded Spaceship _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
