Can be golfed to “Block but True”. Problem also existed for “Code but True”.
Fixed with e31a414 . Tests needed.
> On 3 Dec 2017, at 05:00, Aleks-Daniel Jakimenko-Aleksejev via RT
> wrote:
>
> Still reproducible (2017.11,HEAD(e5b660e))
>
> On 2015-09-18 12:12:49, zef
Can be golfed to “Block but True”. Problem also existed for “Code but True”.
Fixed with e31a414 . Tests needed.
> On 3 Dec 2017, at 05:00, Aleks-Daniel Jakimenko-Aleksejev via RT
> wrote:
>
> Still reproducible (2017.11,HEAD(e5b660e))
>
> On 2015-09-18 12:12:49, zef
Still reproducible (2017.11,HEAD(e5b660e))
On 2015-09-18 12:12:49, zef...@fysh.org wrote:
> Basic introspection methods fail on the value Block but True:
>
> $ ./perl6 -e 'my $a = Block; say $a.WHICH; my $b = Block but True; say
> $b.WHICH'
> Block
> Cannot look up
epresenting everything else. For example,
"(Mu but True).perl" could yield the string "Mu". The bug is that .perl
produces output so broken that .EVAL errors.
-zefram
epresenting everything else. For example,
"(Mu but True).perl" could yield the string "Mu". The bug is that .perl
produces output so broken that .EVAL errors.
-zefram
Do we really want it to dump the source? Or am I misunderstanding something?
On 2015-09-18 12:09:19, zef...@fysh.org wrote:
> $ ./perl6 -e 'my $a = Mu but True; say $a.WHICH; say $a.perl; my $b =
> $a.perl.EVAL'
> Mu+{}
> Mu+{}
> X::Multi::NoMatch exception produced no messag
# New Ticket Created by Zefram
# Please include the string: [perl #126097]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126097 >
If .perl is used to serialise a value of 0 but True, it doesn't represent
the but-Tru
# New Ticket Created by Zefram
# Please include the string: [perl #126098]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126098 >
$ ./perl6 -e 'my $a = Mu but True; say $a.WHICH; say $a.perl; my $b =
$a.perl.EVAL&#
# New Ticket Created by Zefram
# Please include the string: [perl #126099]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126099 >
Basic introspection methods fail on the value Block but True:
$ ./perl6 -e 'my $a
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #100782]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=100782 >
nom does not understand the short form phrases '$val but True&#x
On Sat May 09 04:31:06 2009, moritz wrote:
> This works fine:
>
> $ ./perl6 -e 'enum A ; ("abc" but c).uc.say'
> ABC
>
> This doesn't
>
> $ >./perl6 -e '("abc" but Bool::True).uc.say'
> The but operator can only be used with a role or enum value on the right
> hand side
>
You can now write this
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #72848]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=72848 >
rakudo: 0 but True
rakudo 70667a: OUTPUT«No applicable candidates foun
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #65514]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=65514 >
This works fine:
$ ./perl6 -e 'enum A ; ("abc" but c).uc.say'
ABC
This doesn't
$ >./pe
etting the value to the enum
value that means "nope". For example, there isn't a "true" property,
per se. There's a Boolean role/property with a boolean attribute that
can have the value either true or false. When you say "but true",
it first makes sure that
correctly, adding a role at runtime using but
> : won't override any methods defined by the class itself (but it
> : will override inherited methods). But then if I create a class
> : that has its own method of saying whether it's true or not, does
> : that mean that
[EMAIL PROTECTED] (Larry Wall) writes:
> is classof($x)
Ouch. $x's class isn't a property or trait of it?
> class AnonClass is classof($x) does FooBar { }.bless($x, foobar => bar)
I don't understand what the bit at the end is doing. This is calling .bless
on the overriden method? And I'm not
Larry Wall wrote:
> Maybe there's an intermediate syntactic form like:
>
> $x but subclass MyClass does FooBar[bar] { }
IMHO, C should be defined as generating a singleton class that
derives from the variable's class and composes a specified role - but not
neccessarily a I role. How about de
On Fri, Dec 19, 2003 at 12:24:29PM -0700, Luke Palmer wrote:
: Abhijit A. Mahabal writes:
: > On Fri, 19 Dec 2003, Larry Wall wrote:
: >
: > > On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote:
: > > : Of course, when I do:
: > > :
: > >
Abhijit A. Mahabal writes:
> On Fri, 19 Dec 2003, Larry Wall wrote:
>
> > On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote:
> > : Of course, when I do:
> > :
> > : my $x = 0 but (true|false);
> > :
> > : then what happens?
> >
>
On Fri, 19 Dec 2003, Larry Wall wrote:
> On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote:
> : Of course, when I do:
> :
> : my $x = 0 but (true|false);
> :
> : then what happens?
>
> That's the problem with making them methods. Any such operational
On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote:
: Of course, when I do:
:
: my $x = 0 but (true|false);
:
: then what happens?
That's the problem with making them methods. Any such operational
definition is going to get you in trouble. I think I like them better
as
ide any methods
: defined by the class itself (but it will override inherited methods). But then
: if I create a class that has its own method of saying whether it's true or not,
: does that mean that "but true" and "but false" won't do anything to it?
:
;
> >
> > ...
> >
> >
> > then somewhere in a function
> >
> > return Complex::new(0,0) but true;
>
> Alternatively, think of the "simple" properties not as C
> specifications, but as method overrides.
>
> In this case, we're d
ded to a class cannot conflict (per the paper and $Larry), but
traits added at run-time would be a different category. Larry said
something about dynamic derivation of a singleton class, etc.
> But then if I create a class that has its own method of saying
> whether it's true or not,
methods). But then
if I create a class that has its own method of saying whether it's true or not,
does that mean that "but true" and "but false" won't do anything to it?
class Complex {
has $.real;
has $.imag;
...
#Actually, how do we define this?
method asB
> That's not how I see it. The filehandle is naturally true if
> it succeeds. It's the undef value that wants to have more
> information. In fact, you could view $! as a poor-man's
> way of extracting the error that was attached to the last
> undef.
Hmm. Thus?
sub fuu()
{
my $retval is err
> David Grove writes:
> : > That's not how I see it. The filehandle is naturally true if it
> : > succeeds. It's the undef value that wants to have more information.
> : > In fact, you could view $! as a poor-man's way of extracting the error
> : > that was attached to the last undef.
> :
> : If
David Grove writes:
: > That's not how I see it. The filehandle is naturally true if it
: > succeeds. It's the undef value that wants to have more information.
: > In fact, you could view $! as a poor-man's way of extracting the error
: > that was attached to the last undef.
:
: If I were wealt
> That's not how I see it. The filehandle is naturally true if it
> succeeds. It's the undef value that wants to have more information.
> In fact, you could view $! as a poor-man's way of extracting the error
> that was attached to the last undef.
If I were wealthy enough in time and patience t
h,
except in the places you currently would see "0 but true". I think the
status will generally be returned as the actual argument, and extra
info attached as a property:
return undef is error("Gorkulator borked");
That is, it's returning the exception that it *would*
--- Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> Yes... if you are using only the "true" property. But assume func()
> can attach either "true" or "false" to its return value (and in the
> latter case, also the "what_went_wrong" property to indicate the
> cause,
> $retval.what_went_wrong("Gork
> The statement I read was "true in any possible way", which implies that
> if $retval had a "true" property, the result of func would be
> irrelevant, since if func gave 0, "any possible way" would see the
> "$retval is true" property and take the "it worked" route.
>
> Thus, this code:
>
> my
> false"
>
> Any feature is incomprehensible if one is not used to it. Pointers
> in C are incomprehensible if one has never met the concept before.
>
> As far as I understand one rationale behind the "false (in Perl 5
> terms)
> but true (in Perl 6 terms)" is t
33 matches
Mail list logo
