I lost track of that draft. Sorry. Three comments and a bonus.
1. for_every_part jars. We don't have file_into, we don't have any_child.
I don't mind underscores per se, but I do mind heterodoxy. Using
gluedtogethernames sometimes, using underscore_names sometimes and
camelCaseNames sometimes makes the language unnecessarily messy. (Yes,
I know we don't have camelCase anywhere. At least not that I've
noticed.)
2. break has been difficult in C for decades when nested loops are used,
do we need to repeat it? Wouldn't it be better to tie break and its
loop explicitly, e.g. with an identifier? The identifier would be
optional on the loop and mandatory on the break.
3. Perhaps I'm tired, but it wasn't clear to me whether if two loops are
nested, both operate on _every_ bodypart, O(n^2) and all, or whether
the inner only operates on children of the bodypart currently accessed
by the outer loop. The former seems correct, but I'm not thrilled to
have O(n^2) mandatory behaviour, and O(n^m) possible if more than two
levels is supported.
Bonus. Philosophy. I like the way :anychild without for_every_part
works. That makes it possible to do parallel processing instead of
sequential. If I want to process, say, ten or a hundred thousand
messages with a single sieve script, that becomes important. I can
transform the test to a database lookup and the query planner will
generally do well. This makes some clever reprocessing of an entire
mailbox possible. "Your new sieve script would have filed <these>
messages into <that mailbox>. Do you want to move them now?". break and
perhaps for_every_part torpedoes such transformations. I wonder whether
that's necessary. I wonder whether it's really the same problem as the
O(n^m) behaviour of nested for_every_part.
Arnt