Aubrey Jaffer scripsit: > I am suggesting the following restriction be *removed* from the > "Procedure calls" section of RnRS: > > _Note:_ Although the order of evaluation is otherwise unspecified, > the effect of any concurrent evaluation of the operator and > operand expressions is constrained to be consistent with some > sequential order of evaluation. The order of evaluation may be > chosen differently for each procedure call.
[snip] > Removing a restriction would seem to be justified solely on the basis > of: > > Programming languages should be designed not by piling feature on > top of feature, but by removing the weaknesses and restrictions > that make additional features appear necessary. This is a fine example of the rhetorical fallacy of equivocation. The second quotation refers to removing restrictions on programmers. The first quote imposes a restriction on implementations, partly for the benefit of those same implementations, but mostly for the benefit of programmers trying to reason about side effects. R5RS has a restriction that the forms in a BEGIN must be evaluated sequentially and in order. Lifting this restriction would benefit some uses, but would force programmers to devise a new way of doing things sequentially and in order (like output), because they could no longer rely on BEGIN. Like all contracts, a spec specifies the agreements between implementers and users. Each accepts some restrictions. -- Using RELAX NG compact syntax to John Cowan <[email protected]> develop schemas is one of the simple http://www.ccil.org/~cowan pleasures in life.... --Jeni Tennison <[email protected]> _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
