On 11/01/2010 12:41 PM, Damian Conway wrote: > Moritz wrote: > >>> $value !~~ Junction && $value ~~ $junction >> >> In general this definition makes it impossible to return a list of >> eigenstates from the junction. Just think of junctions containing Code >> objects. > > Well, that's a deficiency in smartmatching: that Callable ~~ Code doesn't > check for identity between the two objects. Likewise the Regex ~~ Regex > doesn't check for identity. Likewise Range ~~ Range testing for identical > endpoints. Etc. ;-)
Sorry, I disagree. It's exactly what smartmatching was designed to be. If you don't want that kind of behaviour, use infix:<eqv> or infix:<===> instead. > The definition of eigenvalues() is supposed to be abstractly > descriptive, not specifically constructive. The idea is simply: any > "leaf" state inside the junction to which the junction could collapse. Junctions only collapse to Bool::True or Bool::False. So an attempt to fix your definition could be 'any "leaf" state inside the junction, which makes the junction collapse to True if compared to the junction as a whole' but begs for a more concrete comparison rule. For which, IMHO smartmatching would be nice, since I mostly use junctions for smartmatching. Which brings us into the dilemma I mentioned before. >> Right; but afaict it's the only thing that can actually be implemented. >> And because it doesn't make all too much sense, it's specced to be private. > > Fine. But please change the name anyway. > > If we all agree it's not returning eigenstates, and some of us believe it > *can't* every return eigenstates, then it certainly shouldn't be called > C<.eigenstates>. Agreed. Cheers, Moritz
