On Mar 15, 12:57 pm, datawea...@gmail.com (Jon Lang) wrote: > The problem that Richard just identified is that Junctions don't fully > manage to hide themselves when it comes to their method calls. [...] > I'm thinking that maybe Junction shouldn't be a type. Instead, it > should be a "meta-type", in (very rough) analogy to the concept of the > meta-operator. In particular, Junction bears a certain resemblance to > the hyper-operator.
A couple of months ago I started a thread "rfc: The values of a junction" where I suggested that a solution tot he problem was to add a "grep" meta-operator that would enable an operator-based collapse of junctions. My suggested syntax from that thread was: my @values = 0..21 |==| $junc_value; Or my @values = Int |==| $junc_value; The idea was to match the range against the (possibly) junctional value, but return the set of matching values rather than just a True/ False comparison (Any binary operator that returns something boolean- like would be usable in the |<op>| meta chars. Given changes to meta- ops since then, perhaps my @values = 0..21 G== $junc_value would be more consistent. The advantage of using an operator over the existing "grep" method is that it could reasonable be expected to handle infinite ranges (and infinite junctions) analytically (in finite time). The advantage of using the operator over the "eigenstates" method is that it doesn't assume any knowledge pf the nature of the junction: "all", "any", "one", "none" -- the operator would do the right thing without any additional user-introspection.
