On Thu, Aug 23, 2012 at 09:50:07PM +0200, Leon Timmermans wrote: > > You're proposing that: > > > > any(9,10,11) ~~ \&is_prime > > > > be equivalent to: > > > > is_prime(any(9,10,11)) > > > > but what if I want it to mean what it's supposed to mean: > > > > any(is_prime(9), is_prime(10), is_prime(11)) > > If «is_prime(any(9,10,11))» is not equivalent to «any(is_prime(9), > is_prime(10), is_prime(11))», it's not a junction in the first place. > It's just an abstraction that fakes it half of the time and leaks like > a sieve the other half. Supporting them in a few circumstances and not > in others seems silly and wrong to me. IMO doing them half-arsed is > worse than not doing them at all. This is kind of my main concern. It requires all implementations of overloaded ~~ to be sure to handle a lot of different cases, which can easily be forgotten (since testing on the lhs of ~~ is fairly uncommon). This feels similar to the concerns that were raised about the pluggable smartmatch - things would seem to work in the common case, but would fail in the uncommon case if every smartmatch overload didn't explicitly make sure to handle the pluggable form. It's certainly possible to make things that work given this implementation, but it pushes a lot of work back on the user, which seems vaguely suboptimal to me (especially when is_prime(any(9, 10, 11)) should still work fine for any sane or reasonable implementation of any()). -doyThread Previous | Thread Next