Okay, I'll respond because you made an interesting point, but you've also pissed me off. Let's follow this through: for a start, just because it's an intuitive doesn't mean it's wrong. However, you made me think that may be we can force at compile time that all() must take a non-empty list of Booleans where we can be sure that the problem domain should never have empty lists. I think with modern typing we can do this with dependent types (but I'm not an expert on this, but you have raised an interesting possibility, thanks).
However there are domain cases where empty lists still make sense, so you're still going to have to account for them in a rational way, and that means logically consistent, and I guarantee we will be back to what you don't like. But that's ok.
Now where you've pissed me off is this bit
> n this case, one possible solution is to not have the concept of "falsy" and "truthy"
and
> forcing 'all' to take a mapping closure
Perhaps you could un-piss me off by explaining what the bloody hell those two are supposed to mean – pretend I'm a language designer that interested in your idea (which actually I am) – what are you asking me to implement?
However there are domain cases where empty lists still make sense, so you're still going to have to account for them in a rational way, and that means logically consistent, and I guarantee we will be back to what you don't like. But that's ok.
Now where you've pissed me off is this bit
> n this case, one possible solution is to not have the concept of "falsy" and "truthy"
and
> forcing 'all' to take a mapping closure
Perhaps you could un-piss me off by explaining what the bloody hell those two are supposed to mean – pretend I'm a language designer that interested in your idea (which actually I am) – what are you asking me to implement?