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

[Pascal J. Bourguignon]

Ron Garret <ron at flownet.com> writes:

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

Oh, and of course, you can always write:

    (< 1 0 (error "Duh!"))

or:

    (and (< 1 0) (< 0 (error "Re-Duh!")))

to mean the former or the later!



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.