Larry Wall wrote: > Sigh. The current design of Junctions is quite extensible *because* > it is based on a real type. You can easily write operators that > work only on Junctions, just as you can easily write operators that > are transparent to Junctions or autothread on Junctions by declaring > their arguments to take Object or Any, respectively.
Right; that was the solution to which I was referring. > That being said, the reason Junctions are there in Perl 6 is primarily > *linguistic* rather than mathematical; Perl 6 has a Set type because > we've had this argument already. Anyone who extends Junctions to > try to do some kind of set theory is on the road to Perdition, or at > least the road to Brain Pretzels Without End, amen. Agreed. My own concern has nothing to do with set theory; it's in making sure that there's an easy way to distinguish between method calls that are supposed to be fielded by the Junction itself (e.g., "give me perl for the Junction") and method calls that are supposed to be fielded by the Junction's eigenstates (e.g., "give me a Junction of perls for the eigenstates of this Junction") - bearing in mind that the Junction _does_ try to stay out of the way and pretend to be (a superposition of) its individual eigenstates as much as possible. _That's_ why I suggested pushing its methods into HOW: not to make it "not a type", but rather to ensure that its method calls will never clobber (or be clobbered by) the method calls of its eigenstates. This allows the programmer to continue to think of "1 | 2" as "an item, although I'm not sure which one" most of the time, and only as "a Junction" when it is convenient to do so (i.e., by making his intent explicit). The business of referring to it as a "meta-type" was perhaps an unfortunate digression from my main point; but I mentioned it to justify why I would feel comfortable with allowing Junction to put things in HOW: not only the practical reason that you wouldn't need to present _another_ HOW-like collection of methods to keep the Junction's stuff out of the way, but also because Junction _is_ a strange creature in that it's a collection of items that can usually be treated as a single (indeterminate) item - and this would highlight this fact to the programmer, perhaps making the task of understanding the Junction easier by providing an analogy to another language feature that has similar properties (i.e., meta-operators). Admittedly though, this latter reason takes a back seat to the practicalities. Bottom line, the goal is to keep Junction's methods from conflicting with its members' methods. -- Jonathan "Dataweaver" Lang
