more inconsistent coercions for Bool

[p6rt]

Migrated from rt.perl.org#130969 (status was 'open')

Searchable as RT130969$

[p6rt]

From zefram@fysh.org

On the same lines as [perl #​127019], the Bool.Real coercion is surprisingly inconsistent with Bool.Int and Bool.Numeric​:

True.^does(Real) True True.^does(Numeric) True True.^isa(Int) 1 True.Real True True.Numeric 1 True.Int 1

The same goes for coercions from other enum types.

-zefram

[p6rt]

From @geekosaur

On Thu, Mar 9, 2017 at 2​:55 PM, Zefram \perl6\-bugs\-followup@​perl\.org wrote​:

The same goes for coercions from other enum types.

This should be your hint. Enums *are* numeric, specifically Int. I don't know what language you are trying to force Perl 6 to be, but you might want to consider the possibility that Perl 6 is not that language but instead is Perl 6.

-- brandon s allbery kf8nh sine nomine associates allbery.b@​gmail.com ballbery@​sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[p6rt]

From zefram@fysh.org

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

[p6rt]

From @geekosaur

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 \zefram@​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 allbery.b@​gmail.com ballbery@​sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[p6rt]

From zefram@fysh.org

Brandon Allbery via RT wrote​:

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 would be interested in seeing that discussion.

(That said, there may actually be some lingering inconsistency left over from when Bool had to be special-cased

I haven't noticed any such inconsistency between Bool and other enums. That's certainly not the cause of the present inconsistent coercions, which happen equally with Order​:

Less.Int -1 Less.Real Less Less.Numeric -1

-zefram

[p6rt]

From @geekosaur

The discussion I'm thinking of starts around here​: http://colabti.org/irclogger/irclogger_log/perl6?date=2017-03-04#l1490

On Thu, Mar 9, 2017 at 4​:04 PM, Zefram \zefram@​fysh\.org wrote​:

Brandon Allbery via RT wrote​:

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 would be interested in seeing that discussion.

(That said, there may actually be some lingering inconsistency left over from when Bool had to be special-cased

I haven't noticed any such inconsistency between Bool and other enums. That's certainly not the cause of the present inconsistent coercions, which happen equally with Order​:

Less.Int -1 Less.Real Less Less.Numeric -1

-zefram

-- brandon s allbery kf8nh sine nomine associates allbery.b@​gmail.com ballbery@​sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[p6rt]

From sidhekin@gmail.com

On Thu, Mar 9, 2017 at 9​:17 PM, Brandon Allbery \allbery\.b@​gmail\.com wrote​:

On Thu, Mar 9, 2017 at 2​:55 PM, Zefram \perl6\-bugs\-followup@​perl\.org wrote​:

The same goes for coercions from other enum types.

This should be your hint. Enums *are* numeric, specifically Int. I don't know what language you are trying to force Perl 6 to be, but you might want to consider the possibility that Perl 6 is not that language but instead is Perl 6.

  I need another hint.

  How does that explain that True.Real is True, while True.Int is 1?

Eirik

[p6rt]

From @skids

On Fri, 10 Mar 2017 00​:31​:58 -0800, sidhekin@​gmail.com wrote​:

On Thu, Mar 9, 2017 at 9​:17 PM, Brandon Allbery \allbery\.b@​gmail\.com wrote​:

On Thu, Mar 9, 2017 at 2​:55 PM, Zefram \perl6\-bugs\-followup@​perl\.org wrote​:

The same goes for coercions from other enum types.

This should be your hint. Enums *are* numeric, specifically Int. I don't know what language you are trying to force Perl 6 to be, but you might want to consider the possibility that Perl 6 is not that language but instead is Perl 6.

I need another hint.

How does that explain that True.Real is True, while True.Int is 1?

Eirik

Current behavior​:

$ perl6 -e 'say Less.Real' -1 $ perl6 -e 'say True.Real' 1

(both Ints)

I think this is consistent with how the .Numeric/.Real role "casts" are used. I'll dump a long-winded explanation of that in 127019 but the short form is they get you the narrowest (without losing your information) compatible (with the particular role you requested) type which is capable of using the built-in arithmetic candidates.

Classes that already do Numeric behave in a manner consistent to how a class that does not do Numeric would, because outside of arithmetic, .Numeric/.Real is most often used as a well-known way to extract numeric values from a compound class.