Damian Conway wrote:
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the narrow
purpose for which they were introduced.
Problem 2 could be solved by defining a new (and public!)
C<.eigenstates> method in the Junction class. [...]
I think that you're proposed solution is a bit too specific: it assumes
that when you say "eigenstates", what you really mean is "the set of
values that would compare equal to". I have no problem with that
concept, expect that I think that it would be better realized as a
meta-operator -- I previously proposed G[op] as that operator ("G" for
grep) -- to reinforce the idea that you only get to peer into a junction
if you state the operator.
> sub factors (Num $n) {
> ( $n/any(1..$n) ).eigenstates.grep({ $^q.Int == $q });
> }
could be:
sub factors (num $n) { ^$n G[==] $n/any(1..$n) }
if $passwd ~~ UNACCEPTABLE {
say "Unacceptable password. Don't use any of these:";
say UNACCEPTABLE.eigenstates¬».fmt("\t%s\n");
}
Could be
if $passwd ~~ UNACCEPTABLE {
say "Unacceptable password. Don't use any of these:";
say (::Str G[eq] UNACCEPTABLE)».fmt("\t%s\n")
}
And, of course:
method eigenstates( Junction $v : ) {
::Any G=== $v
}
Operations other than equality could be used:
say (^10 G[<] one(3,7));
> 3 4 5 6
I suggest a meta-op instead of simply using the "grep" method to
strongly imply that the implementation would need to be analytic in nature.
