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

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

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

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

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

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

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

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

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.