[perl #131118] [RFC][@LARRY] Implement a way to propagate exceptions in Junctions

2017-05-05 Thread Zoffix Znet via RT
On Fri, 07 Apr 2017 10:08:54 -0700, comdog wrote:
> Consider this junction which you probably shouldn't make but you know
> will happen in the hands of users:
> 
> any( 5, 'flarg' ) == 5
> 
> Despite having an element that satisfies the condition, it blows up
> because one of them doesn't:
> 
> > any(5, "flarg") == 5
> Cannot convert string to number: base-10 number must begin with
> valid digits or '.' in '⏏flarg' (indicated by ⏏)
>   in block  at  line 1
> 
> But, it should't matter that what happens with any other parts of the
> junction if at least one of them satisfies the condition. You could,
> for instance, evaluate that differently so the new junction looks
> something like this:
> 
> any( True, Failure );
> 
> But, I don't think it should evaluate to another junction at all. The
> comparison operator should evaluate to a Boolean. That Failure will
> never matter because it's equivalent to False.


Thank you for the report. However, I'm going to reject the ticket.

As previous replies mentioned, there's no problem with Failures in a Junctions,
they work as any other value. The actual explosion in OP's code happens when 
one of the
Failures—created when 'flarg' was coerced to Numeric—is used as a value for
the purposes of evaluating the `==` op with it. That's when the Exception
gets thrown.

I'm unsure if one of the suggestions was to catch such exceptions and turn
them into Failures again... If it were, it's not a good idea, since Junctions
are not meant to be well-introspectable and just silencing exception like that
is bound to end in tears.

Some of the other suggestions were to make `try` Junctionable and stuff
a Junction into $! variable. If that's possible to do at all, IMO it should be
done as a trial in a module first, to evaluate usability and any issues
with the compatibility with core code.

Lastly, I added a 'Failures and Exceptions' section to Junction docs[^1] that
explains the issues raised in this ticket as well as shows some of possible
ways to attain the goals, if really necessary.

[1] https://github.com/perl6/doc/commit/7628708384bdc049d74c997fc2059cf57fcf5a57


[perl #131118] [RFC][@LARRY] Implement a way to propagate exceptions in Junctions

2017-05-05 Thread Zoffix Znet via RT
On Fri, 07 Apr 2017 10:08:54 -0700, comdog wrote:
> Consider this junction which you probably shouldn't make but you know
> will happen in the hands of users:
> 
> any( 5, 'flarg' ) == 5
> 
> Despite having an element that satisfies the condition, it blows up
> because one of them doesn't:
> 
> > any(5, "flarg") == 5
> Cannot convert string to number: base-10 number must begin with
> valid digits or '.' in '⏏flarg' (indicated by ⏏)
>   in block  at  line 1
> 
> But, it should't matter that what happens with any other parts of the
> junction if at least one of them satisfies the condition. You could,
> for instance, evaluate that differently so the new junction looks
> something like this:
> 
> any( True, Failure );
> 
> But, I don't think it should evaluate to another junction at all. The
> comparison operator should evaluate to a Boolean. That Failure will
> never matter because it's equivalent to False.


Thank you for the report. However, I'm going to reject the ticket.

As previous replies mentioned, there's no problem with Failures in a Junctions,
they work as any other value. The actual explosion in OP's code happens when 
one of the
Failures—created when 'flarg' was coerced to Numeric—is used as a value for
the purposes of evaluating the `==` op with it. That's when the Exception
gets thrown.

I'm unsure if one of the suggestions was to catch such exceptions and turn
them into Failures again... If it were, it's not a good idea, since Junctions
are not meant to be well-introspectable and just silencing exception like that
is bound to end in tears.

Some of the other suggestions were to make `try` Junctionable and stuff
a Junction into $! variable. If that's possible to do at all, IMO it should be
done as a trial in a module first, to evaluate usability and any issues
with the compatibility with core code.

Lastly, I added a 'Failures and Exceptions' section to Junction docs[^1] that
explains the issues raised in this ticket as well as shows some of possible
ways to attain the goals, if really necessary.

[1] https://github.com/perl6/doc/commit/7628708384bdc049d74c997fc2059cf57fcf5a57