Re: The ,= operator
Hi Joe,
I can reproduce your results on Rakudo_2020.10, but I'm afraid I don't
have much more to say about the ",=" operator since I'm unfamiliar
with it.
Do the "docs" page(s) make more sense changing the phrase
"class-dependent" behavior to "hash-dependent" behavior?
Best, Bill.
On Thu, Nov 26, 2020 at 2:29 PM Joseph Brenner wrote:
>
> I was going through the operator list in the documentation the
> other day, and I noticed this one:
>
> postfix ,=
>
> Creates an object that concatenates, in a class-dependent way,
> the contents of the variable on the left hand side and the
> expression on the right hand side:
>
> my %a = :11a, :22b;
> %a ,= :33x;
> say %a # OUTPUT: «{a => 11, b => 22, x => 33}»
>
> I was playing around with this a bit and now I'm wondering what
> it's talking about with that "class-dependent way".
>
> To start with, I've got a small issue with that example:
> that particular pair-input syntax is my least favorite.
> Flipping around the order of key and value when the value is a numeric...?
>
> And it isn't needed to demo the operator, any pair input syntax works.
> I might argue that examples should favor the form that "say" is
> going to spit back to you. This would be clearer at a glance:
>
>my %b = a => 11, b => 22;
>%b ,= x => 33;
>say %b; # OUTPUT: «{a => 11, b => 22, x => 33}»
>
> But where it gets interesting is trying a ,= on something besides
> a hash. Let's try arrays, where I would expect this to push a
> value onto the array:
>
> my @r = 'a', 'b', 'c';
> say @r; # [a b c]
> @r ,= 'd';
> say @r; # (\Array_53270704 = [Array_53270704 d])
> dd @r; # Array @r = ((my @Array_37059224) = [@Array_37059224, "d"])
>
> It's difficult for me to even see what that is or how I would use it:
>
> say "keys: ", @r.keys; # keys: (0 1)
> say @r[0]; # (\Array_44472736 = [Array_44472736 d])
> say @r[1]; # d
>
> So it *does* push a 'd', but it first mangles the original
> contents of the array. It looks like @r[0] now has some sort
> of circular pointer back to @r.
>
> Whatever this "class-dependent" behavior is, I would suggest
> it's a "fail". Could this be a bug?
Re: The ,= operator
@r ,= 'd'; The above expands to: @r = @r , 'd'; That in turn passes a list of two values to the LHS receiver. That receiver is `@r`, an array, and what arrays do with `=` is to empty themselves and then assign the list of elements on the RHS of the `=` into corresponding `Scalar`s stored in each element of the array. So you end up with two elements. **And the first element is a reference to itself**. > say @r; # (\Array_53270704 = [Array_53270704 d]) > dd @r; # Array @r = ((my @Array_37059224) = [@Array_37059224, "d"]) I get both the `gist` (`say`) and `dd` are weird. But that's because the value is both infinite and recursively so. What else can they to do? One could argue that what they're doing is just about the most useful thing that could be done. > So it *does* push a 'd', but it first mangles the original > contents of the array. It looks like @r[0] now has some sort > of circular pointer back to @r. It's doing exactly what your code told it to do, and the display is doing perhaps the most useful thing that can be done, as affirmed by the fact you've correctly guessed the right way about the circular pointer, but have wrongly guessed that that is a resulting of it "mangling".. > Whatever this "class-dependent" behavior is, I would suggest > it's a "fail". Could this be a bug? It isn't really anything to do with "class dependent" behaviour. Perhaps more importantly, what improvement do you propose? > I was playing around with this a bit and now I'm wondering what > it's talking about with that "class-dependent way". First, to get one suspicion I have out of the way, I suspect it may actually be object dependent. If so, calling it "class dependent" may just be intended to be a helpful simplification, and even if it isn't, I'm going to roll that way and only refer to the dependent aspect as "class dependent", even if it is in reality potentially object dependent. There are two aspects to what happens: * Syntax -- specifically, use of a `$` sigil on the LHS. * Class dependence. Syntax is determined by the compiler, before a class gets to have any say about what to do. So let's deal with syntax first. If the LHS receiver of `=` starts with a `$` sigil then "item assignment" applies. my $foo = 1; $foo = 2,3; # Useless use of ... 3 say $foo;# 2 Note how the *first* value listed on the right is assigned to the variable, but any other values are LOUDLY discarded (i.e. there's a warning message) by the *compiler*: In all other scenarios, "list assignment" applies. The compiler passes *all* the RHS values to the LHS receiver, What then happens depends on the receiver. It's important to be clear that this first aspect is all about the `$` sigil. 42= 99,100; # "Cannot modify an immutable Int (42)" error No `$` sigil on the LHS so the above is *list assignment*. my \foo = $; foo = 99, 100; say foo; # (99 100) Again, the assignment to `foo` is *list assignment*. Conversely: my $bar := 42; $bar = 99,100; # Both "Useless use of ... 100" warning and "Cannot assign" error There's a `$` sigil on the LHS so the above is *item assignment*. $ = 99,100; # Useless use of constant integer 100 Again, a `$` sigil, so *item assignment* applies. The `$` sigil has to be at the *start* of what is being considered by the compiler: ($,$foo) = 4,5,6; # 4 thrown away explicitly. 6 thrown away silently. say $foo;# 5 If the LHS starts with a `$` then, at runtime, it is given a single value. If it is a `Scalar`, all it does is the metaphoric equivalent of storing that value "inside" the `Scalar` container. This is what it means to "assign to" a `Scalar`. In all other cases the compiler passes *a list of values* at runtime to the receiver. What that receiver does with the list depends on the receiver's class. > that particular pair-input syntax is my least favorite. > Flipping around the order of key and value when the value is a numeric...? > > And it isn't needed to demo the operator, any pair input syntax works. > I might argue that examples should I think the docs reflect a desire to show rich examples that go beyond the bare minimum. For some purposes that's a great thing. For others it's a bad thing. If you are willing to put a *great deal* of effort into helping evolve the doc by both patiently discussing your concerns AND also *writing* and/or *rewriting* doc in accord with a mandate to do so based on a rough consensus, where rough doesn't mean unfriendly to any of those involved, then I am 100% with you, and may even be talked into helping a bit. Otherwise, I think that by far the most important thing is that we support folk who both really care about improving the doc and who will keep working on it in a manner that helps sustain progress for both our doc and that of the individuals doing the work. > favor the form that "say" is going to spit back to you. I ag
Fwd: The ,= operator
I accidentally sent this privately. -- Forwarded message - From: Ralph Mellor Date: Fri, Nov 27, 2020 at 6:06 PM Subject: Re: The ,= operator To: William Michels > I can reproduce your results on Rakudo_2020.10, but I'm afraid I don't > have much more to say about the ",=" operator since I'm unfamiliar > with it. It's working as it should. It *might* be possible to improve the display. `a ,= b` is just shorthand for `a = a , b`. This same pattern is used for any `a op= b`. So `a += b` is the same as `a = a + b`. So `@r ,= 'd'` is the same as `@r = @r, 'd'`. Which makes @r a self-referential infinitely recursive data structure. How does one display it? I can imagine an argument that it would be better if the *gist* (as against the `dd`) switched from: @array_123456789 to @r or @array-that-contains-itself or @array-that-contains-itself_1 But I'm not sure if any of those suggestions are *improvements*, nor whether they are viable / sensible. > Do the "docs" page(s) make more sense changing the phrase > "class-dependent" behavior to "hash-dependent" behavior? The "class dependent" behavior is really a red herring. See my other other reply to Joe for a detailed discussion.
Re: The ,= operator
First off, much thanks to Ralph Mellor for his detailed explanations. Ralph Mellor wrote: > @r ,= 'd'; > > The above expands to: > > @r = @r , 'd'; Okay, that makes sense. So the circular reference I thought I was seeing is really there, and it's working as designed. There isn't anything very useful in this behavior though, is there? Also (the immediate point, really) this isn't described very well in the documentation. Just to be thoroughly clear, since with a hash this works: my %all_at_once = a => 1, b => 2, c => 3; my %in_stages = a => 1; %in_stages ,= b => 2; %in_stages ,= c => 3; (Now %in_stages is the same as %all_at_once.) My first guess was that for arrays, this would work: my @all_at_once = 'a', 'b', 'c'; my @in_stages = 'a'; @in_stages ,= 'b'; @in_stages ,= 'c'; But here, while @all_at_once is just: [a b c] the array @in_stages has a peculiar structure containing circular references. > > say @r; # (\Array_53270704 = [Array_53270704 d]) > > dd @r; # Array @r = ((my @Array_37059224) = [@Array_37059224, "d"]) > I get both the `gist` (`say`) and `dd` are weird. > But that's because the value is both infinite and recursively so. > What else can they to do? I'm not sure there is much else they could do. Flagging the circularity in some way? say @r; # ( [ d]) > > So it *does* push a 'd', but it first mangles the original > > contents of the array. It looks like @r[0] now has some sort > > of circular pointer back to @r. > It's doing exactly what your code told it to do, and the display > is doing perhaps the most useful thing that can be done, as > affirmed by the fact you've correctly guessed the right way > about the circular pointer, but have wrongly guessed that that > is a resulting of it "mangling".. Well, actually, I noticed the circular reference by playing with .keys and explicitly dereferencing with [0] and [1]. And not to quibble too much, but if you didn't want this to do that to the array, then it *is* "mangling" it. I get that it's working as designed, but I think that means you're never going to want to do this. It could be it should even be warning or erroring out. > > Whatever this "class-dependent" behavior is, I would suggest > > it's a "fail". Could this be a bug? > It isn't really anything to do with "class dependent" behaviour. In which case, the documentation could use some improvement. (Actually, saying that some behavior in Raku is class dependent is kind of redundant... it's all class dependent in one way or another.) > Perhaps more importantly, what improvement do you propose? Well, I just mentioned a few. I always want to see more examples in the docs. What else would you use ,= with besides a hash? Just as an aside: It could be my confusion here is another form of something else that keeps tripping me up. Merging two hashes together is pretty simple: my %h_all = %h1, %h2; But doing the same thing with arrays is going to require slipping the values out of the containers: my @a_all = | @a1, | @a2; So the two cases aren't all that parallel.
Re: The ,= operator
About the documentation in general... > > that particular pair-input syntax is my least favorite. > > Flipping around the order of key and value when the value is a numeric...? > > > > And it isn't needed to demo the operator, any pair input syntax works. > > I might argue that examples should > > I think the docs reflect a desire to show rich examples that go > beyond the bare minimum. > > For some purposes that's a great thing. For others it's a bad thing. Yes, precisely. I can understand wanting to have some flashy virtuoso raku code out there to show off the language, but I typically want to see at least a few very basic examples that don't rely too much on other knowledge (how much is too much is always a tricky one). > If you are willing to put a *great deal* of effort into helping evolve the > doc by both patiently discussing your concerns AND also *writing* > and/or *rewriting* doc in accord with a mandate to do so based on > a rough consensus, where rough doesn't mean unfriendly to any of > those involved, then I am 100% with you, and may even be talked > into helping a bit. No, no, when you want to talk someone into doing a lot of work you tell them how much *fun* it is. In general I like the material in the docs, but often I think the features need to be introduced with a few more simple examples early on (in the spirit of SYNOPSIS sections). I would think this kind of thing could just be done piecemeal without being a massive project. I guess if we were talking about a policy change to say, always have input data that looks like the .gist output, that might take some discussion, but even that isn't something that would have to be rolled out all at once. > Otherwise, I think that by far the most important thing is that we > support folk who both really care about improving the doc ... Sorry if it sounds like I'm griping a lot. My tone often comes off as pretty negative even when I don't intend it. > > favor the form that "say" is going to spit back to you. > > I agree with the sentiment of reducing cognitive load on readers. Yes, that's exactly it.
IO::Socket::Async::SSL on new Linux
Appreciation to https://github.com/jnthn for his recent update to https://github.com/jnthn/p6-io-socket-async-ssl. My lab consists of the below Linux platforms, where the starred four distributions were snagged on IO::Socket::Async::SSL, thereby holding back cro. Not tonight! CentOS Linux release 7.9.2009 (Core) * CentOS Linux release 8.2.2004 (Core) Debian GNU/Linux 10 (buster) Fedora 32 (Thirty Two) * Fedora 33 (Thirty Three) Oracle Linux Server 7.9 * Oracle Linux Server 8.3 openSUSE Leap 15.2 Ubuntu 18.04.5 LTS * Ubuntu 20.04.1 LTS Gratitude for getting cro via IO::Socket::Async::SSL enabled on these more recent distros. - Mark
