Re: junctions with given/when
Hi Larry, I have a follow up question based on your May 31 email that I'm hoping you may be able to answer. In that email, you wrote: > In my opinion, the most consistent approach is to disallow any > autothreading of the argument to .ACCEPTS, such that > 3.ACCEPTS(any(3,4)) simply returns False.… I think treating the > unrecognized $other as a raw Mu returning False (rather than a > threadable Any returning a junction) is the most consistent, if not > always in line with everyone's expections, which are not consistent. > :) I did some digging into why 3.ACCEPTS(any(3)) currently returns True, and it turns out that it does so because you spec'd and implemented it that way. The Roast test is at github.com/Raku/roast/commit/53f468 and the implementation is at github.com/rakudo/rakudo/commit/28a769 – and that commit has the message > This is probably how most people will expect smartmatching to work. Of course, you're free to change your mind – some rules never change :) But I'd like to understand if this _is_ a deliberate change in your thinking and, if so, what changed your mind. From where I stand, the logic from 2015-Larry is pretty convincing, but is sounds like you no longer agree with that guy> I'd be very interested to know what convinced you. Thank you in advance, Daniel
Re: junctions with given/when
Hi Larry, I have a follow up question based on your May 31 email that I'm hoping you may be able to answer. In that email, you wrote: > In my opinion, the most consistent approach is to disallow any > autothreading of the argument to .ACCEPTS, such that > 3.ACCEPTS(any(3,4)) simply returns False.… I think treating the > unrecognized $other as a raw Mu returning False (rather than a > threadable Any returning a junction) is the most consistent, if not > always in line with everyone's expections, which are not consistent. > :) I did some digging into why 3.ACCEPTS(any(3)) currently returns True, and it turns out that it does so because you spec'd and implemented it that way. The Roast test is at github.com/Raku/roast/commit/53f468 and the implementation is at github.com/rakudo/rakudo/commit/28a769 – and that commit has the message > This is probably how most people will expect smartmatching to work. Of course, you're free to change your mind – some rules never change :) But I'd like to understand if this _is_ a deliberate change in your thinking and, if so, what changed your mind. From where I stand, the logic from 2015-Larry is pretty convincing, but is sounds like you no longer agree with that guy> I'd be very interested to know what convinced you. Thank you in advance, Daniel
Re: junctions with given/when
On Thu, Nov 4, 2021 at 7:27 PM Joseph Brenner wrote:
>
> Yes, thanks, I'd managed to forget that we had a go-round
OK. Cool. I wasn't sure if it was the same issue (hence my aiui
qualification). It's helpful to hear confirmation you consider this
to be the same issue.
Btw, I'd say it was not only a go-round, but led to Larry's helpful
wrap up of / response to the discussion.
(And inspired me to research smartmatch/junction bugs already
filed in our existing bug queues, and succinctly document my results.)
So, from my perspective, the main thing was that it was a
particularly *productive* go-round.
In addition, although it *almost* stalled there, with no-one
filing an issue, the process by which issues get resolved,
it has now moved on.
If there are aspects that are worrying, it's that an issue
wasn't filed as a consequence of the discussion, and, as
a related concern, when issues *are* filed the quality of
the filing and follow up is troubling.
> I'm actually finding this one profoundly depressing
Hopefully your attention has now moved on to other things,
but in case that wasn't the case, or the underlying thoughts
haven't gone away, and at the risk of me being the one to
bring you back to them, I will continue.
> but I probably shouldn't get into it.
I think it's healthy to get into it, as I note you did. Feelings
need to be aired in your own mind, and shared with others.
First and foremost, I hear you. Feeling profoundly blue about
Raku is like feeling profoundly blue about anything. It sucks.
Unfortunately -- but also *fortunately* -- feelings, unlike thoughts,
are like waves, tides, seasons -- they come and go and there's
nothing that can (nor should) be done to stop them flowing one
way and then the next.
> My thoughts are running along lines like "how is it possible
> something like this is still up-in-the-air at this date?"
Unlike someone expressing their feelings, which doesn't need
to be rationally understood but just is what it is, thoughts are
are different thing.
This summary of your thoughts suggests that, behind your
feeling of depression, was *confusion*. ("How is it possible...?")
I suspect that that's *not* it, but perhaps it is?
If it *was* confusion, then would it be helpful to discuss how
an issue like this still being up in the air is not only very much
possible but is one of thousands in Raku -- as it is in pretty
much all PLs? (Python's issue tracker contains 57,000 bugs
with 7,000 with status "open", and others "pending", "closed
(wontfix)" and so on.)
(Or was the confusion about it apparently being the case that
no issue had been filed?)
If it *wasn't* about confusion, was it instead a sense that,
while it's reasonable that Python and other mature PLs
(used and developed by relatively huge communities) have
many more such issues still outstanding decades after devs
have first encountered them, Raku is supposed to be a new
PL, so shouldn't have long standing bugs?
Or something else?
> "is this language too complex to be implemented cleanly?"
Perhaps it's worth acknowledging that Python, which is
supposed to be "simple", is far more complex to implement
cleanly than Raku.
> and so on.
When thoughts are entrained to a feeling, there's usually no
stopping them. Hopefully you've had a day or two break from
where you were at and that has helped. And/or my email here
has helped. And/or your Raku study group, presuming you do
continue with that. Then again, perhaps not. Maybe thing to do
is to step away from spending time with Raku, at least for a while?
--
love, raiph
Re: junctions with given/when
If this pull request is merged:
https://github.com/rakudo/rakudo/pull/4620
you will get a deprecation notice at the end of your program of the locations
in your code that need changing.
Liz
> On 5 Nov 2021, at 19:54, Joseph Brenner wrote:
>
> Yes, this feels like natural Raku code to a lot of us:
>
>given any( $o1, $o2 ) { when { ... } }
>
> If there's some rule like, "don't use junctions
> on the left hand side of a smartmatch" that
> hasn't been made clear, and there's certainly no
> roast tests that check this, so consequently the
> behavior has drifted around.
>
> The latest word from Jonathan Worthington seems
> to be that the current behavior should probably
> be reverted *for now*, but a later language
> version of Raku will change it again, albeit more
> consistently.
>
> So if you were serious about writing Raku code
> (and not just playing around with it, as I mostly am)
> you'd need to have a list in mind of these things
> that are kinda-sorta-deprecated. Otherwise, you'd
> just have to expect breakage on upgrade in the future.
>
>
> On 11/4/21, yary wrote:
>> and I realize that what I just typed doesn't help a whole lot, what if you
>> have a junction of things and you want to tell if any/one/all/none
>> smartmatch the same thing... OK..
>>
>> -y
>>
>>
>> On Thu, Nov 4, 2021 at 6:38 PM yary wrote:
>>
>>> Something that helps me reason about this is thinking of how regular
>>> expressions match against strings, to remember that which goes on which
>>> side is important...
>>>
"this has a Q in it" ~~ / 'Q' / # of course this works
>>>
>>> ｢Q｣
>>>
/ 'Q' / ~~ "this has a Q in it" # of course this breaks
>>>
>>> Regex object coerced to string ...
>>>
>>>
say do given "this has a Q in it" { when / 'Q' / {"has a Q"}; default
>>> {"no match"}}
>>>
>>> has a Q
>>>
say do given / 'Q' / { when "this has a Q in it" {"has a Q"}; default
>>> {"no match"}}
>>>
>>> Regex object coerced to string ...
>>>
>>> I did have a place in the earlier discussion. I eventually realized that
>>> if I thought of junctions as analogous to regular expressions, then it
>>> was
>>> easier to remember which side of the smartmatch or given/when to put it.
>>>
>>> -y
>>>
>>>
>>> On Thu, Nov 4, 2021 at 3:31 PM Joseph Brenner wrote:
>>>
> ... we'd need to go
> through detailed, calm, measured discussion if we're to minimize
> the pain it seems we'll inevitably endure pain to dig ourselves out
> of the hole we'd be in.
Yes, this could be a bad one.
>>>
>>
Re: junctions with given/when
Yes, this feels like natural Raku code to a lot of us:
given any( $o1, $o2 ) { when { ... } }
If there's some rule like, "don't use junctions
on the left hand side of a smartmatch" that
hasn't been made clear, and there's certainly no
roast tests that check this, so consequently the
behavior has drifted around.
The latest word from Jonathan Worthington seems
to be that the current behavior should probably
be reverted *for now*, but a later language
version of Raku will change it again, albeit more
consistently.
So if you were serious about writing Raku code
(and not just playing around with it, as I mostly am)
you'd need to have a list in mind of these things
that are kinda-sorta-deprecated. Otherwise, you'd
just have to expect breakage on upgrade in the future.
On 11/4/21, yary wrote:
> and I realize that what I just typed doesn't help a whole lot, what if you
> have a junction of things and you want to tell if any/one/all/none
> smartmatch the same thing... OK..
>
> -y
>
>
> On Thu, Nov 4, 2021 at 6:38 PM yary wrote:
>
>> Something that helps me reason about this is thinking of how regular
>> expressions match against strings, to remember that which goes on which
>> side is important...
>>
>> > "this has a Q in it" ~~ / 'Q' / # of course this works
>>
>> ｢Q｣
>>
>> > / 'Q' / ~~ "this has a Q in it" # of course this breaks
>>
>> Regex object coerced to string ...
>>
>>
>> > say do given "this has a Q in it" { when / 'Q' / {"has a Q"}; default
>> {"no match"}}
>>
>> has a Q
>>
>> > say do given / 'Q' / { when "this has a Q in it" {"has a Q"}; default
>> {"no match"}}
>>
>> Regex object coerced to string ...
>>
>> I did have a place in the earlier discussion. I eventually realized that
>> if I thought of junctions as analogous to regular expressions, then it
>> was
>> easier to remember which side of the smartmatch or given/when to put it.
>>
>> -y
>>
>>
>> On Thu, Nov 4, 2021 at 3:31 PM Joseph Brenner wrote:
>>
>>> > ... we'd need to go
>>> > through detailed, calm, measured discussion if we're to minimize
>>> > the pain it seems we'll inevitably endure pain to dig ourselves out
>>> > of the hole we'd be in.
>>>
>>> Yes, this could be a bad one.
>>>
>>
>
Re: junctions with given/when
and I realize that what I just typed doesn't help a whole lot, what if you
have a junction of things and you want to tell if any/one/all/none
smartmatch the same thing... OK..
-y
On Thu, Nov 4, 2021 at 6:38 PM yary wrote:
> Something that helps me reason about this is thinking of how regular
> expressions match against strings, to remember that which goes on which
> side is important...
>
> > "this has a Q in it" ~~ / 'Q' / # of course this works
>
> ｢Q｣
>
> > / 'Q' / ~~ "this has a Q in it" # of course this breaks
>
> Regex object coerced to string ...
>
>
> > say do given "this has a Q in it" { when / 'Q' / {"has a Q"}; default
> {"no match"}}
>
> has a Q
>
> > say do given / 'Q' / { when "this has a Q in it" {"has a Q"}; default
> {"no match"}}
>
> Regex object coerced to string ...
>
> I did have a place in the earlier discussion. I eventually realized that
> if I thought of junctions as analogous to regular expressions, then it was
> easier to remember which side of the smartmatch or given/when to put it.
>
> -y
>
>
> On Thu, Nov 4, 2021 at 3:31 PM Joseph Brenner wrote:
>
>> > ... we'd need to go
>> > through detailed, calm, measured discussion if we're to minimize
>> > the pain it seems we'll inevitably endure pain to dig ourselves out
>> > of the hole we'd be in.
>>
>> Yes, this could be a bad one.
>>
>
Re: junctions with given/when
Something that helps me reason about this is thinking of how regular
expressions match against strings, to remember that which goes on which
side is important...
> "this has a Q in it" ~~ / 'Q' / # of course this works
｢Q｣
> / 'Q' / ~~ "this has a Q in it" # of course this breaks
Regex object coerced to string ...
> say do given "this has a Q in it" { when / 'Q' / {"has a Q"}; default
{"no match"}}
has a Q
> say do given / 'Q' / { when "this has a Q in it" {"has a Q"}; default
{"no match"}}
Regex object coerced to string ...
I did have a place in the earlier discussion. I eventually realized that if
I thought of junctions as analogous to regular expressions, then it was
easier to remember which side of the smartmatch or given/when to put it.
-y
On Thu, Nov 4, 2021 at 3:31 PM Joseph Brenner wrote:
> > ... we'd need to go
> > through detailed, calm, measured discussion if we're to minimize
> > the pain it seems we'll inevitably endure pain to dig ourselves out
> > of the hole we'd be in.
>
> Yes, this could be a bad one.
>
Re: junctions with given/when
> ... we'd need to go > through detailed, calm, measured discussion if we're to minimize > the pain it seems we'll inevitably endure pain to dig ourselves out > of the hole we'd be in. Yes, this could be a bad one.
Re: junctions with given/when
Yes, thanks, I'd managed to forget that we had a go-round on this one six months ago, even though that one came out of the Raku Study Group I run. I'm actually finding this one profoundly depressing, but I probably shouldn't get into it. My thoughts are running along lines like "how is it possible something like this is still up-in-the-air at this date?" and "is this language too complex to be implemented cleanly?" and so on. On 11/4/21, Ralph Mellor wrote: > Aiui, we discussed this issue in May and Larry explained > that this would happen. > > Larry doesn't speak up much, and I realized a few months > later that it seemed no one had done anything about what > he had said. So I filed an issue: > > https://github.com/Raku/problem-solving/issues/297 > > Aiui, until we listen to Larry, accept he's right, and fix Rakudo, > the results when the topic of a smart match is a Junction will > randomly depend on which version of Rakudo you're using. > > -- > love, raiph >
Re: junctions with given/when
On Thu, Nov 4, 2021 at 6:34 PM Ralph Mellor wrote: > > Aiui, until we listen to Larry, accept he's right, and fix Rakudo, > the results when the topic of a smart match is a Junction will > randomly depend on which version of Rakudo you're using. Further, aiui, when we do, there may be a world of pain due to widespread coding that goes against what Larry has said should be the case for sanity. As I note in the issue, I have used the idiom: where .all ~~ foo a LOT. Uhoh. Which is why I filed it as a problem solving issue. Because if things are as I understand Larry is saying they are, then we'd need to go through detailed, calm, measured discussion if we're to minimize the pain it seems we'll inevitably endure pain to dig ourselves out of the hole we'd be in. -- love, raiph
Re: junctions with given/when
Aiui, we discussed this issue in May and Larry explained that this would happen. Larry doesn't speak up much, and I realized a few months later that it seemed no one had done anything about what he had said. So I filed an issue: https://github.com/Raku/problem-solving/issues/297 Aiui, until we listen to Larry, accept he's right, and fix Rakudo, the results when the topic of a smart match is a Junction will randomly depend on which version of Rakudo you're using. -- love, raiph
Re: junctions with given/when
I see the same as Joseph:
$ raku
Welcome to 퐑퐚퐤퐮퐝퐨™ v2021.06.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2021.06.
To exit type 'exit' or '^D'
> say do given all(3,7) { when Int { "both are Int" }; default {"not
similar"} };
not similar
> say so do all(3,7) ~~ Int;
True
> given all(3,7) { say $_; say $_.WHAT; }
all(3, 7)
(Junction)
> given all(3,7) { say so $_ ~~ Numeric; }
True
> $*VM
moar (2021.06)
>
On Tue, Nov 2, 2021 at 9:45 AM Joseph Brenner wrote:
> A given/when construct using a junction isn't quite doing what I'd expect.
>
> I'd thought that that would confirm that both elements were Int:
>
> say do given all(3,7) { when Int { "both are Int" }; default {"not
> similar"} };
> ## not similar
>
> But this does what I thought it would:
>
> say so do all(3,7) ~~ Int;
> # True
>
> And the given seems to put the junction in $_ as expected:
>
> given all(3,7) { say $_; say $_.WHAT; }
> # all(3, 7)
> # (Junction)
>
> And you can use that junction in a smartmatch explicitly
>
> given all(3,7) { say so $_ ~~ Numeric; }
> # True
>
Re: junctions with given/when
Joseph Brenner wrote:
> Andy Bach wrote:
>> Joseph Brenner wrote:
>>> I'd thought that that [this] would confirm that both elements were Int:
>>> say do given all(3,7) { when Int { "both are Int" }; default {"not
>>> similar"} };
>>> ## not similar
>> I get a different result
>> $ raku -e ' say do given all(3,7) { when Int { "both are Int" }; default
>> {"not similar"} };'
>> both are Int
>> $ raku -v
>> This is Rakudo version 2020.05.1 built on MoarVM version 2020.05
> That's interesting. I just re-built from github and I'm still
> seeing the behavior I reported:
>
> raku -e 'say do given all(3,7) { when Int { "both are Int" }; default {"not
> similar"} };'
> not similar
> raku --version
> Welcome to Rakudo™ v2021.10-43-ga8329f6fd.
But if I run with an older installation, using 퐑퐚퐤퐮퐝퐨 v2020.10,
I see it work correctly. This is looking like a bug introduced
fairly recently.
I opened an issue on this:
https://github.com/rakudo/rakudo/issues/4615
Re: junctions with given/when
That's interesting. I just re-built from github and I'm still
seeing the behavior I reported:
raku -e 'say do given all(3,7) { when Int { "both are Int" };
default {"not similar"} };'
not similar
That's with:
raku --version
Welcome to Rakudo™ v2021.10-43-ga8329f6fd.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2021.10-22-g938098118.
On 11/2/21, Andy Bach wrote:
>> I'd thought that that would confirm that both elements were Int:
> say do given all(3,7) { when Int { "both are Int" }; default {"not
> similar"} };
> ## not similar
>
> I get a different result
> $ raku -e ' say do given all(3,7) { when Int { "both are Int" }; default
> {"not similar"} };'
> both are Int
>
> $ raku -e ' say do given all(3,"x") { when Int { "both are Int" }; default
> {"not similar"} };'
> not similar
>
> $ raku -e ' say do given all(3,7) { when Int { $_ }; default {"not
> similar"} };'
> all(3, 7)
>
> $ raku -v
> This is Rakudo version 2020.05.1 built on MoarVM version 2020.05
>
> From: Joseph Brenner
> Sent: Tuesday, November 2, 2021 11:45 AM
> To: perl6-users
> Subject: junctions with given/when
>
> CAUTION - EXTERNAL:
>
>
> A given/when construct using a junction isn't quite doing what I'd expect.
>
> I'd thought that that would confirm that both elements were Int:
>
> say do given all(3,7) { when Int { "both are Int" }; default {"not
> similar"} };
> ## not similar
>
> But this does what I thought it would:
>
> say so do all(3,7) ~~ Int;
> # True
>
> And the given seems to put the junction in $_ as expected:
>
> given all(3,7) { say $_; say $_.WHAT; }
> # all(3, 7)
> # (Junction)
>
> And you can use that junction in a smartmatch explicitly
>
> given all(3,7) { say so $_ ~~ Numeric; }
> # True
> CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary.
> Exercise caution when opening attachments or clicking on links.
>
>
Re: junctions with given/when
> I'd thought that that would confirm that both elements were Int:
say do given all(3,7) { when Int { "both are Int" }; default {"not similar"}
};
## not similar
I get a different result
$ raku -e ' say do given all(3,7) { when Int { "both are Int" }; default
{"not similar"} };'
both are Int
$ raku -e ' say do given all(3,"x") { when Int { "both are Int" }; default
{"not similar"} };'
not similar
$ raku -e ' say do given all(3,7) { when Int { $_ }; default {"not similar"}
};'
all(3, 7)
$ raku -v
This is Rakudo version 2020.05.1 built on MoarVM version 2020.05
From: Joseph Brenner
Sent: Tuesday, November 2, 2021 11:45 AM
To: perl6-users
Subject: junctions with given/when
CAUTION - EXTERNAL:
A given/when construct using a junction isn't quite doing what I'd expect.
I'd thought that that would confirm that both elements were Int:
say do given all(3,7) { when Int { "both are Int" }; default {"not
similar"} };
## not similar
But this does what I thought it would:
say so do all(3,7) ~~ Int;
# True
And the given seems to put the junction in $_ as expected:
given all(3,7) { say $_; say $_.WHAT; }
# all(3, 7)
# (Junction)
And you can use that junction in a smartmatch explicitly
given all(3,7) { say so $_ ~~ Numeric; }
# True
CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary. Exercise
caution when opening attachments or clicking on links.
