That's a beautiful example of adapting the underlying language until it makes the implementation practically a descriptive syntax for spelling out the solution in text.
I think I'll route my manager to that post, as he not ten hours ago wondered about what functional programming buys you which is difficult to do with the kind of imperative heritage he has (he grew up on Fortran, back in the day).
This may not an issue for you or for your own work environment, but if I continue to publish techniques that people wish to share professionally I'm imagining that some may find the name "Cat Dancer" to be an unnecessary distraction. So I put up another copy here in case:
Unrelated, but I would advise against working for or with people that would either choke on an online alias (that is not even inflammatory :-), and/or fail to grasp at the quality of your work, reasoning and communication about the concepts therein, measuring your aptitude from that data.
...but I'll definitely hand you that signing it with your contact information likely makes it easier for those that do spot you to get in touch, for whichever reason. Which might sometimes be more interesting than vetting for ideal recruiters, especially if you want to work someplace that delegates recruiting to people outside of where the actual work happens, so the above paragraph gets half moot.
Since the arity information is lost for any complement ~f (for instance, but any general or composed function will do) of a function f:
(def complement (f) (fn args (no (apply f args))))
automatic currying turns all composed functions into second degree citizens, which adds programmer burden to the use of any function, in keeping track of whether it will invoke or return a new function.
For what its worth (and proper names, to unmuddle confusion, can be worth a lot), the above mentioned "curry" function in ANSI Common Lisp is called partial application, that is, you apply a few fixed arguments and return a new function that takes a lower number of arguments, with the first already pre-populated.
Excellent for making lots of custom functions for producing different HTML tags, and that kind of thing. In javascript, libraries often name that function "partial", which saves "curry" for currying.
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.
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.
Rather bizarrely, on my Linux system at least, make-directory is creating directories with the sticky bit set... and I didn't see anywhere in the MzScheme's manual a way to set the umask. Perhaps someone else will have better luck.
If this can be fixed, the make-directory* function in the MzScheme file.ss library will usefully create intervening directories, like mkdir -p does.
