Larry wrote:
Never. Truth is relative in Perl. Having a "true" literal would
imply that objects couldn't decide whether they're true or not, unless
the true literal really means a superposition of all the possible
true values of every type. Which is kinda hard to write, especially
since a type could decide on the fly whether a value is true.
Yes. Rather than C<true> and C<false> constants, we may
have C<true> and C<false> predicates (that correctly handle the
nuances of Perl 6 booleans). We will certainly have
unary prefix operators for determining truth/falsehood
(i.e. C<?> and C<!>).
: If so, what happens when you combine them? Are they associative,
: distributive, worse?
I don't think those terms apply till you collapse.
Yep. The superpositional operators effectively build a value that's
like a parse tree of the original operand values.
I dislike the term "flexprs" even though it's kinda cute. I don't
think it communicates what's really going on any better than
"superpositions". Druther call them something ugly like "junctions"
if that communicates better.
I certainly don't mind "junctions".
Takes me back to my electrical engineering days! ;-)
I'll call them "junctions" from now on.
Maybe it could be "junks" for short. So you'd read
$a ~~ 1|2|3
as "Does $a match this junk?"
Err. Yeah. Great.
;-)
: What's $a?
:
: 1 | 5 & 10
: (1|5) & 10
: (1&10) | (5&10) ?
The second, if any. But maybe it should be a no-no to append to a
junk of a different kind.
I think not. It's important to be able to compose "higher-order"
superpositions. And to be able to do so via the assignment variant.
We've already said that appending to a
junk of the same type doesn't add "parentheses". This may be one
of those situations where the assignment operators are overloaded
separately from the basic ops.
I don't believe that's necessary or appropriate. I think it's
important to be able to "append" consistently, regardless of the
current value of the LHS.
Damian
