- you never use 'for directly, but in cases where you are sure the bounds are OK.
The "problematic" (few) occurrences of 'for only appears in arc.arc and strings.arc which are typical librairies files.
What makes arc.arc and strings.arc less valid examples of for usage? They're Arc programs, too. Should they not inherit the elegance they're attempting to define? (While still balancing efficiency, of course, cf. the tutorial: http://ycombinator.com/arc/tut.txt)
To the contrary, because arc.arc and strings.arc use for I think they make perfect examples -- which would make your first statement untrue, since you had to write extra bounds-checking.
- you sometimes, rarely, also need to directly use a descendant 'for ('down). Only once in all Arc (but once = it is needed):
So it's a pity that for this one time, you can't use 'for, and have to ressort using yet another loop construct that is here for... non-existing problems.
You're ignoring that down has another purpose. As you say, the need for a descending loop is rare. But the need for for to only go in one direction is much less rare (more on that later).
for the vast, vast majority of looping, you use higher-level loop constructs (each/repeat/etc.), so there is no problem w/ incorrect bounds, assuming the lib writer is not a moron.
So you'd also want to foist the responsibility of not being a "moron" onto every user of for? If other loops are already used to avoid silly bugs, why not for?
I count at least 12 different loop constructs in arc.arc: while, loop, for, down, repeat, each, whilet, whiler, forlen, on, until, noisy-each, and arguably others like evtil and drain.
I find that adding these makes code simpler: they express (and implement) purposeful loops. That's why I can do
(each x xs (prn x))
instead of
(forlen i xs (prn (xs i)))
which can be done instead of
(for i 0 (- (len xs) 1) (prn (xs i)))
which can be done instead of
(loop (= i 0) (< i (len xs)) (++ i) (prn (xs i)))
etc. If I wanted the most general & least to remember, I'd use a goto.
When for tries to infer the direction I want to go, I need to fight it to stop from going in the opposite direction -- to me, this is inconvenient.
Is it coherent than 'posmatch will return nil when pat > seq, where 'headmatch will throw an error in the same case (even stranger knowing 'posmatch actually calls 'headmatch)?
I agree that headmatch has odd behavior here. But with the fixed behavior (i.e., your patch):
Just because the function to which you funnel input sanitizes data doesn't mean you should be supplying bad values. Further, if we add more error-checking to posmatch to avoid the redundant calls, we're adding even more complexity -- wrestling against for to get it to go just one direction.
"You claimed it'd make the code shorter! Prove it!"
I believe only in reality, in data
Then let's inspect your patch closer:
inspect-patch.arc
(def default (file)
(+ "../arc3.1/" file))
(def patched (file)
(+ "../arc-patch/" file))
(def sexp-tokcount (sexp)
(len (flat sexp)))
(= for-def*
'(mac for (v init max . body)
(w/uniq (gi gm)
`(with (,v nil ,gi ,init ,gm (+ ,max 1))
(loop (assign ,v ,gi) (< ,v ,gm) (assign ,v (+ ,v 1))
,@body))))
down-def*
'(mac down (v init min . body)
(w/uniq (gi gm)
`(with (,v nil ,gi ,init ,gm (- ,min 1))
(loop (assign ,v ,gi) (> ,v ,gm) (assign ,v (- ,v 1))
,@body))))
new-for-def*
'(mac for (v init end . body)
(w/uniq (gi gm gt gf)
`(do
(if (> ,end ,init)
(= ,gt < ,gf +)
(= ,gt > ,gf -))
(with (,v nil ,gi ,init ,gm (,gf ,end 1))
(loop (assign ,v ,gi) (,gt ,v ,gm) (assign ,v (,gf ,v 1))
,@body))))))
; if this calculation is wrong, it should be revealed in logic-savings
(= max-diff* (- (+ (sexp-tokcount for-def*) (sexp-tokcount down-def*))
(sexp-tokcount new-for-def*)))
(def token-total (file)
(sum cadr (tokcount (list file))))
(def token-diff (file1 file2)
(- (token-total file1) (token-total file2)))
(def compare-tokcount (filename)
(let diff (token-diff (default filename) (patched filename))
(if (> diff 0)
(prn "The patch saved " (plural diff "token") " in " filename)
(< diff 0)
(prn "The patch added " (plural (- diff) "token") " to " filename)
(prn "The patch didn't change the token count in " filename))))
(def maximum-savings ()
(prn "The patch could have saved at most (caveat lector) "
(plural max-diff* "token")
" in arc.arc"))
(def logic-savings ()
(let diff (token-diff (default "arc.arc") (patched "arc.arc"))
(if (<= diff max-diff*)
(prn "So, by changing 'for in arc.arc, "
(plural (- max-diff* diff) "token")
" got added to code that used the previous version of 'for")
(err "miscalculated the maximum number of tokens you could save"))))
(map compare-tokcount '("arc.arc" "strings.arc" "news.arc"))
(prn)
(maximum-savings)
(logic-savings)
At the REPL
arc> (load "inspect-patch.arc")
The patch saved 9 tokens in arc.arc
The patch added 2 tokens to strings.arc
The patch didn't change the token count in news.arc
The patch could have saved at most (caveat lector) 17 tokens in arc.arc
So, by changing 'for in arc.arc, 8 tokens got added to code that used the previous version of 'for
nil
To explain the "caveat", I assume the most this new for could change is: (a) remove the single-direction for and down, (b) add the bidirectional for, and (c) leave any other piece of code that used for/down unchanged (save switching the word "down" to the word "for").
With these assumptions (and by inspecting the code), the assessment seems correct: arc.arc nets 8 additional tokens to stop for from going backwards. It's not that the token count is shorter from having for go both directions; it's that the code you've added to avoid for's new behavior isn't quite enough to outweigh the savings from removing down's definition.
In actuality, you'll wind up saving far less than 9 tokens because of multiple evaluation bugs:
i.e., 7 more tokens, totaling 14 more tokens, which outweighs the original figure. So, nothing is even really saved in arc.arc. Though, of course, the rewrites could be shorter with something like once-only (see towards the end of http://gigamonkeys.com/book/macros-defining-your-own.html).
Further, strings.arc and news.arc did not get shorter (strings.arc even got a little longer). The only way it seems that un-patched code could get shorter is if it had to go either up or down and the order didn't matter -- unlike code in the files inspected.
Therefore, this patch can either make new code longer or make you hope that for doesn't iterate in a direction you don't want it to (as in news.arc), unless you needed to do the Arc 3.1 equivalent of
(if (< start end)
(for i start end ...)
(> start end)
(for i end start ...))
which, with this patch, could be replaced with
(for i start end ...)
which is shorter.
As infrequently as such code occurs (0 times in the standard Arc 3.1 distribution, so far as I can tell), this does not yield big space savings. If it does occur frequently enough, it shouldn't outweigh the need for single-direction iterations, but would probably instead be made into a separate macro:
(mac between (var bound1 bound2 . body)
...)
Additionally, you assert that having an extra loop construct entails an unnecessary mental burden for the programmer. I disagree. It's not a burden if its purpose is specific: if you want to repeat a block of code, use
(repeat n ...)
instead of
(for temp 1 n ...)
If you want to iterate over the length of a sequence, use
(forlen i xs ...)
instead of
(for i 0 (- (len xs) 1) ...)
Moreover, if you want to iterate upwards through a range of integers, use
