Maybe warn when thunking *.foo ~~ $bar constructs?

[zoffixznet]

Had the user wondering why subset Tuesday of Date where *.day-of-week ~~ 2; doesn't work as expected.

The reason is ~~ is not an op that gets closed over, so that where clause is actually a thunk that has a smartmatch inside of it, with the whatevercode being just an arg. This doesn't give an warnings or error and just gives False even when given correct date object.

Perhaps this case should warn, same as we warn in, for example { *.so } about "double closure"?

[tisonkun]

hmm, * could either be a Whatever or a WhateverCode, is this the problem?

[ab5tract]

On Wed, Jul 18, 2018 at 8:16 AM, 陈梓立 ***@***.***> wrote: hmm, * could either be a Whatever or a WhateverCode, is this the problem?

In the case of *.&method, it is always a WhateverCode. The issue is rather that *.&method ~~ Thing is not going to DWIM for the user that is expecting the whole expression to be a WhateverCode. Instead it is creating a where clause which is always false (smartmatching a WhateverCode against an Int isn't going to return True).

*.so ~~ WhateverCode

True

subset Foo of Int where *.so ~~ 2

(Foo)

my Foo $f = 2

Type check failed in assignment to $f; expected Foo but got Int (2) in block <unit> at <unknown file> line 1

subset Foo2 of Int where { $_ ~~ 2 }

(Foo2)

my Foo2 $f = 2

2 So, if I understand it correctly, one way to interpret this issue is that creating subsets that don't have an actual Callable should be a compile-time error? Does someone have an example of where a subset without a Callable is useful?

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2086 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAKtmn0duTaVKAmpJ-KDu7boERf1xqiks5uHtKjgaJpZM4VTIiq> .

[zoffixznet]

this issue is that creating subsets that don't have an actual Callable should be a compile-time error?

Nope. The issue is a WhateverCode inside a thunk should be a compile-time warning.

Does someone have an example of where a subset without a Callable is useful?

The where clause supports thunking, so there's an infinite number of examples really

• where 42|5
• where Int|Num
• where 'meows'
• 'where .is-prime`
• ...

[b2gills]

I think if this gets covered by a best practices book, it should tell you to use a literal or a statement rather than a Callable. It should also say to steer clear of writing a WhateverCode there.

subset Foo where 2 | 3;         # literal   (best - declarative)
subset Foo where $_ ~~ 2 | 3;   # statement (next best - same but less declarative)

subset Foo where {$_ ~~ 2 | 3} # block (ok - but best for long code)

subset Foo where * ~~ 2 | 3;    # WhateverCode (- easy to get wrong)

# These don't work because the first part is a WhateverCode,
# but the `~~` doesn't co-mingle with existing WhateverCodes.
# So they test if a WhateverCode smartmatches against 2|3.
# (Always False as WhateverCode doesn't do .Numeric)
subset Foo where *.Int ~~ 2 | 3;
subset Foo where +* ~~ 2 | 3;

Another reason against WhateverCode is that the following doesn't do what you might expect.
(What's interesting is that a new Perl 6 programmer will have a different expectation to a seasoned Perl 6 programmer, and they are both wrong.)

subset Bar where * > 5 && * < 10;

What it does is produce two WhateverCodes * > 5 and * < 10. Since the first is truish, it only uses * < 10.

---

One reason I say that a literal is better is because the code written is always used as the right side of ~~.
(At least theoretically)

# These are all functionally equivalent
subset Foo where  2 | 3;

subset Foo where {2 | 3};

subset Foo where  $_ ~~  2 | 3;
subset Foo where  $_ ~~ {2 | 3};
subset Foo where {$_ ~~  2 | 3 };

subset Foo where  $_ ~~  $_ ~~ 2 | 3;
subset Foo where  $_ ~~ {$_ ~~ 2 | 3};
subset Foo where {$_ ~~  $_ ~~ 2 | 3 };
subset Foo where {$_ ~~ {$_ ~~ 2 | 3}};

subset Foo where  $_ ~~  $_ ~~  $_ ~~ 2 | 3;
subset Foo where {$_ ~~ {$_ ~~ {$_ ~~ 2 | 3}}};

This is also part of the reason … ~~ True always returns True, and … ~~ False always returns False.

---

T.L.D.R.:

I think that any time that someone writes a WhateverCode in a subset and it doesn't get put into place as the matcher it should warn and indicate that it's best to use a literal, statement, or a block. (It may be useful to state that $_ is available.)

[zoffixznet]

writes a WhateverCode in a subset

We should warn about WhateverCodes in thunks (even outside subsets), just as we warn about WhateverCodes in Blocks.

[b2gills]

The reason I took a step away from disallowing WhateverCode entirely is someone might want to use * instead of $_ for looks.

About the only thing that I can come up with is using a specific comparison operator

subset Foo where  * eqv …

subset Foo where $_ eqv …

I can not come up with a better example that wouldn't use $_ twice.
Which is something that a WhateverCode wouldn't even work for.

---

I can see someone saying that a method call on $_ is ugly, and they want to use *.

subset Bar where $_.method() == 42;
subset Bar where  *.method() == 42;
subset Bar where   .method() == 42;

---

I now think that it should always at least warn on a WhateverCode in a where, that tells you to use $_.

And if you write a WhateverCode that doesn't get put into place as the matcher, that it should be a compiler error. As I don't think it's possible to do without getting it wrong.
subset Bar where * > 5 && * < 10;
(Obviously if it adds a significant amount of complexity to the compiler it wouldn't be worth adding)

In a future version, we may consider making a WhateverCode where a compiler error.
The only thing it does over anything else is change the looks of the code, slightly.

[zoffixznet]

The only thing it does over anything else is change the looks of the code, slightly.

But where *.foo has a completely different meaning than where .foo that has nothing to do with looks:

$ perl6 -e 'class Foo { method foo { "x" } }; subset Z where .foo; say Foo ~~ Z'
False
$ perl6 -e 'class Foo { method foo { "x" } }; subset Z where *.foo; say Foo ~~ Z'
True

I don't know how we got from a suggestion of making the "double-dipped" WhateverCode warning in thunks consistent with Blocks, to outright banning an extremely common feature that's part of the 6.c specification, and making the language inconsistent in that where would only accept some Callables just in case someone doesn't know how a WhateverCode works.

[b2gills]

That's because *.foo is going through another level of indirection.
Boolify it.

class Foo { method foo { "x" } }

subset Z where ?.foo;
say Foo ~~ Z; # True

[ab5tract]

On Wed, Jul 18, 2018 at 12:45 PM, Zoffix Znet ***@***.***> wrote: this issue is that creating subsets that don't have an actual Callable should be a compile-time error? Nope. The issue is a WhateverCode inside a thunk should be a compile-time warning.

Ah, I see this now. It is a *very* common issue when people are learning about WhateverCode and I would love it if the compiler could catch it. And of course, a warning is the obviously more polite manuever for a core thingy. Nice catch, Zoffix.

Does someone have an example of where a subset without a Callable is useful? The where clause supports thunking, so there's an infinite number of examples really - where 42|5 - where Int|Num - where 'meows' - 'where .is-prime` - ... Excellent point. (also: D'oh!)

I'm not sure whether it is habit, history, or superstition but I've always leaned on passing Callable objects (generally proper blocks because multi-stage guards are fun but otherwise usually WhateverCode). Thanks for mentioning these specific thunking examples. You have inspired to take a look at how thunk dispatching is handled in core. It's always been a bit of a fuzzy concept to me.

[zoffixznet]

Another user bitten by this issue and a bit of discussion here: http://colabti.org/irclogger/irclogger_log/perl6?date=2018-09-26#l39

00:28 | TimToady | but yeah, it's like the double closure warning
-- | -- | --
00:29 | TimToady | m: my $x = { *.abs == 42 }
00:29 | camelia | rakudo-moar 5a974cb9e: OUTPUT: «=== SORRY!=== Error while compiling <tmp>␤Malformed double closure; WhateverCode is already a closure without curlies, so either remove the curlies or use valid parameter syntax instead of *␤at <tmp>:1␤------> my $x = { *.abs == 42 } ⏏…»
00:29 | Zoffix | yeah
00:29 | TimToady | so there's some prior art there
00:30 | TimToady | in fact, I see that we make that one fatal

[2colours]

Is there any reason why *.foo ~~ $bar couldn't just do the right thing?

I mean, it's not like that smartmatching with a literal WhateverCode instance is ever useful, and from all I know, "whatever currying" is merely a syntactic transformation. The expression that got transformed ought to contain the smartmatch as well - similarly to other "thunky" operators. This is something that seems achievable with RakuAST, isn't it?

[librasteve]

@2colours - I think that this ^^^ is best