Comparisons with a junction return a junction instead of a boolean

[briandfoy]

The docs for Junction says

Junctions collapse into a single value in boolean context.

However, it appears they return another junction:

> 4 > any( 2, 3 )
any(True, True)
> any( 2, 3 ) > 4
any(False, False)

You might explain that by saying this isn't in boolean context yet and it does collapse:

 > ( any( 2, 3 ) > 4 ).so
 False

But, from the docs on >, I expected that the comparison operator itself would provide that already:

returns True if the first argument is larger than the second.

Although not explicit, I take that to mean it evaluates to a Boolean, not a Junction. I don't particularly mind that it returns a Junction as long as its documented as such.

I think that junctions should collapse into unique values and asked about that in perl6: Should junctions collapse unique values?.

[AlexDaniel]

Well… and there is a sentence before the one you pasted, which says:

Junctions autothread over many operations, which means that the operation is carried out for each junction element (also known as eigenstate), and the result is junction of the return values of all those operators.

While I agree that there may be a way to make it even clearer, I am still not sure what is so confusing about it.

As for the documentation on <, are you saying that we should mention junctions for every single operator? What about subs?

I think adding one of your examples to Junction page, like this one:

say 4 > any( 2, 3 ) # OUTPUT: «any(True, True)␤»

will resolve the issue.

[briandfoy]

That auto threading sentence is fine for general operations, but if an operator says it returns True or False, that's what it should return. The confusion comes in when what it does isn't what it says it does.

And, as usual, I'm saying that the docs should document what actually happens. As for what should happen, I'm neutral (as long as it is documented). If the thing that happens isn't what should happen, we should fix that. It is hard to know what should happen without an a priori spec though.

[AlexDaniel]

That auto threading sentence is fine for general operations

Hm… what general operations?

[briandfoy]

A general operation is any operation that you haven't specified yet and can't constrain further until you know what it is.

[finanalyst]

Would it be wrong to say: because of auto threading, a junction operation creates a sort of outer envelop around an expression, so even though an expression like " 4 > any( 2, 3) " appears to have one operator which has a unique result, in reality we have something more like Thread_any( 4 > 2, 4 > 3), which is why we get the junction (True, True) as the result ? If this is correct, it might be useful to explain this, as only by writing this question, I worked out what 'Autothreading' actually meant. If I am wrong, some extra explanation would be useful. Richard

…

On Friday, April 07, 2017 08:33 PM, brian d foy wrote: That auto threading sentence is fine for general operations, but if an operator says it returns True or False, that's what it should return. The confusion comes in when what it does isn't what it says it does. And, as usual, I'm saying that the docs should document what actually happens. As for what should happen, I'm neutral (as long as it is documented). If the thing that happens isn't what should happen, we should fix that. It is hard to know what should happen without an /a priori/ spec though. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1269 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWMnHwkJk28fESjUwKpdRR4M6WeRdSkks5rti0OgaJpZM4M20MK>.

[b2gills]

The &infix:«<» operator does return only True or False

The junction calls it for every one of its values, and creates a junction from that. (simplified)

This happens for everything that doesn't specifically handle Junctions or Mu.

Should we add a boilerplate to every operator/sub/method that it doesn't specifically handle Junctions?

Should this operator be one that collapses a Junction?
(I don't think any currently do)

I will add that Junctions should be Bool-ified as soon as practical, but currently it is up the programmer to determine where that is. (I typically use so for this)