I've talked about the idea of using TUPLE! for "predicates". The specific concept that I had would be that the elements of the tuple would represent the function calls in the order you'd write them:
>> any .even? [1 3 7 10 13] ; parallel to `even? 1`, `even? 3`... == 10 >> all .not.odd? [2 4 6 8] ; parallel to `not odd? 2`, `not odd? 4`... == 8
But I've also been arguing for dots having meaning in ordinary PATH! dispatch, e.g. when not having a leading blank. In that case, I'd said things like "functions wouldn't be on the left side of a dot". But that's a whole different purpose.
Put these two together in the same line, and you might wind up looking at code like:
>> obj: make object! [data: [2 4 6 8]] >> all .not.odd? obj.data. == 8
The BLANK!-headed TUPLE!
.not.odd?matched the skippable parameter type constraint for "PREDICATE!", and is interpreted as chain [:odd? | :not] ...or (-> not odd?) if you are using POINTFREE
obj.data.was interpreted as a non-blank-headed tuple, so it's the argument...and the terminal dot indicates the caller wanted to ensures that obj.data isn't a function .
Is this bad?
If TUPLE! were always inert (as in the original proposal) you'd never see things like that, you'd only see:
>> all .not.odd? obj/data == 8
But I'm now fairly sold on TUPLE! for member selection (looks good) and the terminal dot to say "don't execute" is really promising.
I'll point out that there are ways to avoid the particular juxtaposition of tuples if it bothered you:
>> all .not.odd? pick obj 'data == 8 >> all/predicate obj.data. (-> not odd?) == 8 >> apply 'all [obj.data. /predicate func [x] [not odd? x]] ; syntax pending == 8
So a lot of ways to attack it. And these are advanced features, so you can imagine people writing quite a lot of code without ever doing this kind of thing.
But the bigger philosophical question is about entering the era where TUPLE! and PATH! become candidates for multiple dialected meanings. Is that good or bad?
Dialecting ANY-SEQUENCE! Is Good (in the spirit of the "game")
We don't really have problems when a BLOCK! of code contains PARSE instructions vs. being executed by DO. So why should different purposes for TUPLE! be considered strange?
Having the parts be robust enough to want to use creatively is a good thing. I think it's just new, and figuring out what to do with that newness will likely take some time.