Arc Forumnew | comments | leaders | submitlogin
Value of iteration expressions
12 points by ecmanaut 6162 days ago | 9 comments
Is the value of iteration expressions always nil? I heartily recommend it to be at least a boolean, signifying whether the loop iterated at least once -- as it gives the very terse, readable idiom:

(unless (each x mylist (...)) (no-entries))

and the corresponding:

(if (each x mylist (...)) (then...) (otherwise...))

(Prior art of this idiom in RXML, the Roxen macro language, where you typically see it in templated database outpt with an <emit> loop body is followed by an <else> clause.)

For reference, I'm only just through the tutorial.



5 points by ryantmulligan 6162 days ago | link

I can't think of why this is a bad idea. More information from expression returns is strictly better.

-----

3 points by pg 6161 days ago | link

Sounds like a good idea.

-----

1 point by bogomipz 6161 days ago | link

Returning the last value is probably no harder than a hardcoded t. Most of the time you don't care for more specific than a boolean, but one of those days it might come in handy.

-----

4 points by absz 6161 days ago | link

On the other hand, that operates differently if the last value is nil; in other words, it's a tradeoff and has different semantics. I'm personally inclined to think that a boolean might be more useful.

-----

2 points by ecmanaut 6161 days ago | link

I agree to a point; to be a useful idiom, the semantics of the return value should primarily make code easier to read for humans -- while allowing for the useful flow construct which cuts corners on code length.

I don't find t / nil necessarily be the best range, though; the number of iterations that was looped, if non-zero, nil otherwise, conveys useful information that is often wanted and would presently require explicit code for defining and updating a counter variable that, could instead ideally just be there for you to capture, should you want it.

In languages where zero has boolean falsity, the unmodified iteration count would of course work even better and be more cleanly, but I think nil-or-positive-integer works better in Arc.

If getting the count was presumed to be the more common case (vs just figuring out if a loop ran through its body at all) I would argue for the count, zero or otherwise, but personal experience says you mostly want the "whether", not the "how many?", and that the latter is the occasional useful fringe case that mainly adds extra convenience.

-----

1 point by absz 6161 days ago | link

Given that the number of iterations adds strictly more information, I can't see why that would be a bad idea. I agree that it's not normally what you would want, so the asymmetry between numbers and nil is probably worth it.

-----

3 points by bogomipz 6161 days ago | link

Ah, of course, I take back the suggestion :)

-----

1 point by eds 6161 days ago | link

Don't CL's and Scheme's do allow the user to specify the return value? Maybe this wouldn't necessarily be the case with each, but I think it is correct in spirit to allow the user to control the return value.

-----

1 point by drcode 6162 days ago | link

looks good to me.

-----