[Openmcl-devel] Shortcircuiting of argument evaluation in #'<
ron at flownet.com
Wed Jan 9 10:07:20 CST 2013
On Jan 9, 2013, at 7:49 AM, Stas Boukarev wrote:
> Ron Garret <ron at flownet.com> writes:
>> IMO this is a bug in the spec, not CCL. (< a b c ...) ought to mean
>> (and (< a b) (< b c) ...) , not (let* ((a_ a) (b_ b) ...) (< a_ b_ c_
>> ...)). Putting side-effecting code inside a comparison operator is a
>> Truly Horrible Idea (which is even worse than the previously
>> trademarked Really Bad Idea) and any programmer who wants to write
>> code that relies on it ought to bear the burden of expanding his code
>> into the corresponding LET* rather than impose the burden of running
>> dead code on the entire extant code base. That is too high a price to
>> pay. The spec is not scripture.
> Are you being serious?
> < is an ordinary function, and the order of argument
> evaluation and guarantee of evaluation is exactly prescribed by the
> standard. What's the big idea of randomly disregarding the standard?
I am not "randomly" disregarding the spec. I am observing that the spec as written requires the execution of dead code when comparison operators are used in idiomatic ways. Further, I am opining that requiring the execution of dead code is stupid, and suggesting that this part of the spec is a bug and SHOULD be disregarded FOR THAT REASON.
I understand that I am very likely to lose this argument, but I just wanted to express my opinion that CCL's current behavior is preferable to what the spec requires.
More information about the Openmcl-devel