From @dwarring

[08​:09] <dwarring> r​: my $value = True but False; say $value
[08​:09] <+camelia> rakudo-jvm 196b4f​: OUTPUT«(timeout)»
[08​:09] <+camelia> ..rakudo-{parrot,moar} 196b4f​: OUTPUT«False␤»
...
[08​:10] <masak> rakudo-jvm is all "WARNING. PARADOX. MUST OVERHEAT."
[08​:11] * dwarring heh
...
[08​:11] <dwarring> I'll put in an rakudobug
...
[08​:18] <masak> dwarring​: just be aware, camelia has been known to timeout on rakudo-jvm.
[08​:18] <masak> dwarring​: so it might just be an artifact.
[08​:21] <FROGGS> n​: my $value = True but False; say $value
[08​:21] <+camelia> niecza v24-109-g48a8de3​: OUTPUT«True␤»
[08​:21] <FROGGS> m​: my $value = True but False; say $value
[08​:21] <+camelia> rakudo-moar 196b4f​: OUTPUT«False␤»
[08​:21] <FROGGS> I guess it is about that
[08​:22] <dwarring> this expects 'True' - http://perl6advent.wordpress.com/2010/12/19/day-19-false-truth/
[08​:24] <masak> I kind of expect True, too.
[08​:24] == ajr_ [~quassel@​96-44-210-169.ip.tor.radiant.net] has quit [Ping timeout​: 240 seconds]
[08​:25] <dwarring> r​: my $value = True but False; say ?$value
[08​:25] <+camelia> rakudo-{parrot,jvm,moar} 196b4f​: OUTPUT«False␤»
[08​:25] <masak> because the *value* is still True, kind of. it's just the boolean aspect of it that has been overridden.
[08​:25] <FROGGS> n​: my $value = True but False; say ?$value
[08​:25] <+camelia> niecza v24-109-g48a8de3​: OUTPUT«False␤»
[08​:25] <FROGGS> niecza++

From @coke

On Wed May 21 13​:36​:58 2014, david.warring wrote​:

[08​:09] <dwarring> r​: my $value = True but False; say $value
[08​:09] <+camelia> rakudo-jvm 196b4f​: OUTPUT«(timeout)»
[08​:09] <+camelia> ..rakudo-{parrot,moar} 196b4f​: OUTPUT«False␤»
...
[08​:10] <masak> rakudo-jvm is all "WARNING. PARADOX. MUST OVERHEAT."
[08​:11] * dwarring heh
...
[08​:11] <dwarring> I'll put in an rakudobug
...
[08​:18] <masak> dwarring​: just be aware, camelia has been known to
timeout on rakudo-jvm.
[08​:18] <masak> dwarring​: so it might just be an artifact.
[08​:21] <FROGGS> n​: my $value = True but False; say $value
[08​:21] <+camelia> niecza v24-109-g48a8de3​: OUTPUT«True␤»
[08​:21] <FROGGS> m​: my $value = True but False; say $value
[08​:21] <+camelia> rakudo-moar 196b4f​: OUTPUT«False␤»
[08​:21] <FROGGS> I guess it is about that
[08​:22] <dwarring> this expects 'True' -
http://perl6advent.wordpress.com/2010/12/19/day-19-false-truth/
[08​:24] <masak> I kind of expect True, too.
[08​:24] == ajr_ [~quassel@​96-44-210-169.ip.tor.radiant.net] has quit
[Ping timeout​: 240 seconds]
[08​:25] <dwarring> r​: my $value = True but False; say ?$value
[08​:25] <+camelia> rakudo-{parrot,jvm,moar} 196b4f​: OUTPUT«False␤»
[08​:25] <masak> because the *value* is still True, kind of. it's just
the boolean aspect of it that has been overridden.
[08​:25] <FROGGS> n​: my $value = True but False; say ?$value
[08​:25] <+camelia> niecza v24-109-g48a8de3​: OUTPUT«False␤»
[08​:25] <FROGGS> niecza++

This is from an old advent post that was pre-Christmas; is this actually a bug in current rakudo we should fix, or is the advent post out of date?

--
Will "Coke" Coleda

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

From @dwarring

The behavious still seems the same​:

% perl6 --v
This is Rakudo version 2016.07.1-135-g77724b2 built on MoarVM version 2016.07-16-g85b6537
implementing Perl 6.c.
% perl6 -e'my $s = False but True; say $s; say $s.so;'
True
True

This is inconsistent with​:

% perl6 -e'my $s = 0 but True; say $s; say $s.so;'
0
True

On Tue Aug 09 08​:23​:37 2016, coke wrote​:

On Wed May 21 13​:36​:58 2014, david.warring wrote​:

[08​:09] <dwarring> r​: my $value = True but False; say $value
[08​:09] <+camelia> rakudo-jvm 196b4f​: OUTPUT«(timeout)»
[08​:09] <+camelia> ..rakudo-{parrot,moar} 196b4f​: OUTPUT«False␤»
...
[08​:10] <masak> rakudo-jvm is all "WARNING. PARADOX. MUST OVERHEAT."
[08​:11] * dwarring heh
...
[08​:11] <dwarring> I'll put in an rakudobug
...
[08​:18] <masak> dwarring​: just be aware, camelia has been known to
timeout on rakudo-jvm.
[08​:18] <masak> dwarring​: so it might just be an artifact.
[08​:21] <FROGGS> n​: my $value = True but False; say $value
[08​:21] <+camelia> niecza v24-109-g48a8de3​: OUTPUT«True␤»
[08​:21] <FROGGS> m​: my $value = True but False; say $value
[08​:21] <+camelia> rakudo-moar 196b4f​: OUTPUT«False␤»
[08​:21] <FROGGS> I guess it is about that
[08​:22] <dwarring> this expects 'True' -
http://perl6advent.wordpress.com/2010/12/19/day-19-false-truth/
[08​:24] <masak> I kind of expect True, too.
[08​:24] == ajr_ [~quassel@​96-44-210-169.ip.tor.radiant.net] has quit
[Ping timeout​: 240 seconds]
[08​:25] <dwarring> r​: my $value = True but False; say ?$value
[08​:25] <+camelia> rakudo-{parrot,jvm,moar} 196b4f​: OUTPUT«False␤»
[08​:25] <masak> because the *value* is still True, kind of. it's just
the boolean aspect of it that has been overridden.
[08​:25] <FROGGS> n​: my $value = True but False; say ?$value
[08​:25] <+camelia> niecza v24-109-g48a8de3​: OUTPUT«False␤»
[08​:25] <FROGGS> niecza++

This is from an old advent post that was pre-Christmas; is this
actually a bug in current rakudo we should fix, or is the advent post
out of date?

From @smls

I wouldn't call that inconsistent.

`but True` overrides the boolean aspect of an object, and in the case of an object of type Bool, its value *is* its boolean aspect.

Also, is there any practical benefit to what this ticket asks for, or is it purely meant as a fun gimmick?

From @dwarring

Agree that's not equivalent, this is maybe a better counter example​:

  % perl6 -e'my $s = 0 but 42; say $s'
  0

On Wed Aug 10 10​:51​:20 2016, smls75@​gmail.com wrote​:

I wouldn't call that inconsistent.

`but True` overrides the boolean aspect of an object, and in the case
of an object of type Bool, its value *is* its boolean aspect.

Also, is there any practical benefit to what this ticket asks for, or
is it purely meant as a fun gimmick?

From @smls

You're right, that one *is* inconsistent with `True but False`.

`$bool1 but $bool2` and `$int1 but $int2` should either both override the value, or both *not* override the value.

From @zoffixznet

On Thu, 11 Aug 2016 06​:14​:52 -0700, smls75@​gmail.com wrote​:

You're right, that one *is* inconsistent with `True but False`.

`$bool1 but $bool2` and `$int1 but $int2` should either both override
the value, or both *not* override the value.

There's actually no inconsistency and the infix​:<but> is much less magical​:

The infix​:<but> operator with the RHS that isn't a role *creates* a role with a single method
that is the .^name of the RHS value which returns that value, and uses that role to perform the mixin​:

  <Zoffix> m​: my $s = 0 but class { method ^name ($) { 'warbles' } }.new; say $s.warbles
  <camelia> rakudo-moar e0c0ae​: OUTPUT«warbles.new␤»

So the results you claim are inconsistent actually are​:

  % perl6 -e'my $s = False but True; say $s; say $s.so;'
  True
  True

- `but True` mixes in a role with method called `Bool` that returns `True`
- `say` uses `.gist`, which for Bool objects evaluates the object in Bool context (so, calls .Bool), and so we end up with .Bool from our role that gives True
- The `.so` method uses `.Bool` under the hood, which we overrode to True
= both outputs match

In this example​:

  % perl6 -e'my $s = 0 but True; say $s; say $s.so;'
  0
  True

- Everything is the same as in the previous example, except the original object is an Int
- `say` uses `.gist`, which for Int objects calls .Str method, which we did not override with our mix in, hence why we still get `0` in the output
= outputs differ

And since we know that .gist on Ints calls .Str, we can predict that mixing in a Str object will change the output of `say`​:

  <Zoffix> m​: my $s = 0 but 'meows'; say $s; say $s.so;
  <camelia> rakudo-moar e0c0ae​: OUTPUT«meows␤False␤»

Indeed it did change the output of `say` and since we did not override .Bool this time, the `.so` output gives False now.

So then, if we mixin both a Str and a Bool, we'll affect both outputs​:

  <Zoffix> m​: my $s = (0 but 'meows') but True; say $s; say $s.so;
  <camelia> rakudo-moar e0c0ae​: OUTPUT«meows␤True␤»

So as far as I can see, there's no bug or inconsistency. Closing the ticket.

Cheers,
ZZ

@zoffixznet - Status changed from 'open' to 'resolved'