I admit up front that at this point I am too lazy to read that thread right now but too impatient to wait with my question till later.

What I wonder is whether this can be used to supersede the rather unintuitive

my (@dir, @other);
push @{ -d ? \@dir : \@other } for readdir DH;
[download]

That would work assuming that the second test will only catch elements not already caught by the first one. I'm not sure that would be ideal though - it would limit the use of part to mostly a "catch both grep". On the other hand, if it may copy any element to any number of result lists, that specific use would require redundant tests.

Hmm..

Makeshifts last the longest.

Said Aristotle:

What I wonder is whether this can be used to supersede the rather unintuitive

my (@dir, @other);
push @{ -d ? \@dir : \@other } for readdir DH;
[download]

First of all, I love this perl5 idiom of conditional dereferencing. It is succinct for perl enthusiasts, though probably non-obvious to those new to the language. Hence to your question, can it be more elegant in the part concept described for perl6.

I thought of this as well. For your concept, a simple bang shortcut might suffice (I think this is what you intended, actually):

my(@dir, @other) = part [ -d, ! ] readdir DM;
[download]

This was probably what you proposed, sans-typo. The only difference is a '1', which leads me to believe you neglected a shift key (?).

The general case, however, is something I had already considered. It's not merely the negation of a single conditional, it's the leftovers, the default, of the prior conditionals. So we get something like:

(@foo,@bar,@zap,@slop) := part [ /foo/, /bar/, /zap/, ! ] @source;
[download]

There's the modified beast. A nice fluffy beast. I like it. (I think basing the 'slop' on a surplus of receiving arrays might be pushing the obfu a bit much)

Matt

P.S. Is it just me, or is this starting to resemble a case statement embedded in a loop?

Oh, I do like the ternary deref too - it's just I prefer to use map and grep wherever sensible since they're expressions.

I did indeed mean 1 as in if(1) though. In other words, an expression that is always true and thus catches all elements that fall through to it. I'm not sure how a singular bang is supposed to be parsed - I wouldn't like it to be a special case just for part.

On the other hand, the /foo/, /bar/, /zap/ could (and maybe should, which is what I'm wondering) return duplicate elements, that is, any list element might match several of those and would then show up in several of the result lists. That would be handy for single-pass processing of very large lists.

I am thinking that it might be best to allow for a mixing of both semantics, that is, any true expression may or may not consume the element or pass it on. But how could this best be expressed?

Makeshifts last the longest.