Re: Tweaking junctions

```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.