Self-consistency is itself a fuzzy concept. In any case I am specifically thinking of a discussion recently in IRC which went over why at least some of this is actually self-consistent *for perl 6*. I may be able to dig it up again, or hopefully someone else already has it on tap.
(That said, there may actually be some lingering inconsistency left over from when Bool had to be special-cased because it needed to exist in the setting before Enums could be defined.) On Thu, Mar 9, 2017 at 3:41 PM, Zefram <zef...@fysh.org> wrote: > Brandon Allbery via RT wrote: > >This should be your hint. Enums *are* numeric, specifically Int. > > I'm aware of that, and that's why I call this an LTA rather than > a bug, and why I didn't say conclusively which coercion was wrong. > Indeed, on the basis of the enum/Int subclassing, I proposed in [perl > #127019] that the inconsistency that then existed between Bool.Int and > Bool.Numeric coercions ought to be resolved by making both return the > operand unchanged. The decision was made the other way, that they should > both return a basal Int. > > So I'm not saying in this ticket that it's a priori wrong for True.Real > to return True. On the contrary, the fact that True.^does(Real) makes > that a priori a reasonable answer. The problem is that it's inconsistent > with the results for the similar .Int and .Numeric coercions, and with the > decision on those coercions that was made in [perl #127019]. There are > two ways in which these coercions can be made mutually consistent, > and either would resolve this ticket. > > >I don't know what language you are trying to force Perl 6 to be, > > I'd like it to be a self-consistent language, as far as possible. > I don't recall anyone saying yet that that's an undesirable principle > in the design of Perl 6. > > -zefram > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
