[Openmcl-devel] Shortcircuiting of argument evaluation in #'<

[Ron Garret]

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?

Yes.

> < 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.

rg