Having a consistent ("regular", in the linguistic sense), structure for something like the op= form is obviously very desirable. It's so much easier to teach and learn a rule like "op= has the same effect, whatever "op" is; it takes the variable on the LHS, applies the operator to its contents and the other value on the RHS, then puts the result back on the LHS side. E.g. $x ,= 2 has the same effect as $x = $x + 2 than some irregular, complicated set of conditions in certain circumstances, *E.g. the English conjugation of "to be"; "Me be confused".
In this case, unless I have misunderstood the examples, the complication appears to be in the effect of the operation, regardless of its abbreviation by ,= Perhaps there's a special case that should be pointed out as something that needs more grokking than += or ~=, and discussed under ",", which is actually the tricky operation? On 11/28/20, William Michels via perl6-users <perl6-us...@perl.org> wrote: >> > "Perhaps more importantly, what improvement do you propose?" > > Apologies for top-posting, but what immediately comes to my mind upon > encountering the creation of a self-referential (circular/infinite) > object is proverbially 'going-down-a-level' and trying again. So I > tried 1. 'decontainerizing' the object on the LHS, and then 2. using > the ",=" postfix to add an additional element (or many). Nothing > worked. > > Decont: > https://docs.raku.org/language/glossary#index-entry-decont > > Zen slicing as a possible way of 'de-containerizing' : > https://docs.raku.org/language/subscripts#index-entry-Zen_slices > > Even if the ",=" postfix operator were to gain this ability on > non-hash objects, then hash-objects would be special-cased in **not** > requiring a Zen-sliced decontainerized object on the LHS, so people > would have to consider that outcome. > > Best Regards, Bill. > > > > On Sat, Nov 28, 2020 at 8:33 AM Ralph Mellor <ralphdjmel...@gmail.com> > wrote: >> >> > > @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? >> >> Yes. >> >> Here are some relevant results from a search for "self referential" in >> the #perl6 and #raku logs. >> >> 2006 >> https://colabti.org/irclogger/irclogger_log/perl6?date=2006-01-06#l567 >> > stevan: dunno about ML (or whatever TaPL uses), but IIRC scheme's >> letrec is a form of let which allows things to be self referential >> >> 2012 >> https://colabti.org/irclogger/irclogger_log/perl6?date=2012-01-01#l107 >> my $ff=1; >> constant @primes = >> 2, 3, 5, >> -> $n is copy { repeat { $n += 2 + ($ff=!$ff)*2 } until $n %% none >> @primes ... * > sqrt $n; $n; } >> ... *; >> say @primes[^10]; # OUTPUT«2 3 5 7 11 13 17 19 23 29» >> >> 2012 >> https://colabti.org/irclogger/irclogger_log/perl6?date=2012-10-05#l582 >> > TimToady: I'd like to get to the point where we can do hamming numbers >> self referentially >> constant @hamming = 1, dedup (@hamming X* 2) M (@hamming X* 3) M >> (@hamming X* 5); >> >> 2014 >> https://colabti.org/irclogger/irclogger_log/perl6?date=2014-11-02#l823 >> > lizmat: my main reason for not pursuing self referential structures in >> > .raku >> > lizmat: was that I didn't have a solution for representing them >> > lizmat: thoughts on that are very welcome >> .... >> > moritz: lizmat: I fear it must be printed out exactly like that >> >> 2015 >> https://colabti.org/irclogger/irclogger_log/perl6?date=2015-08-17#l1558 >> > vendethiel: TimToady: I read the backlog a bit, but I'm not sure I read >> > the >> answer to this question: do you want "my @a = 1, @a" to be (1, 1, 1 >> ...) (à la haskell)? >> > TimToady: not sure it makes sense with 'my' due to assignment semantic, >> but would certainly be nice if 'constant' could be self referential >> > TimToady: and we might intuit a lazy if we see the same symbol on the >> > left and right >> > TimToady: haskell obviously never needs to have explicit lazy, since >> > everything already is... >> . >> > Also (the immediate point, really) this isn't described very well >> > in the documentation. >> >> I'd say the first focus is best `.raku`. But perhaps it's already >> optimal. >> Then again, I imagine "thoughts on that are very welcome" still applies. >> >> It's always appropriate to consider improving the doc, especially >> imo if a draft of an improvement is written by, or in cooperation >> with, folk who encountered a problem.. >> >> > Just to be thoroughly clear, since with a hash this works ... >> > My first guess was that for arrays, this would work: >> > But here, while @all_at_once is just: [a b c] the array >> > @in_stages has a peculiar structure containing circular references. >> >> Each hash in a list of hashes is automatically flattened: >> >> my %hash = { :a, :b }, { :c, :d } >> say %hash; # {a => True, b => True, c => True, d => True} >> >> Whereas each array in a list of arrays is not: >> >> my @array = [ :a, :b ], [ :c, :d ]; >> say @array; # [[a => True b => True] [c => True d => True]] >> >> This is the "class dependent" aspect of the semantics of `=`. >> >> You could create a new array type SteamRolled and bind that: >> >> my @array is SteamRolled = [ :a, :b ], [ :c, :d ]; >> say @array; # [a => True b => True, c => True d => True] >> >> Then using the `,=` op would do as you desire. >> >> > say @r; # ( [<CIRCULAR REFERENCE> d]) >> >> "Thoughts are welcome". :) >> >> > 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 hear you don't feel sufficiently heard about it being "mangling", >> but I just wanted to be clear it was not doing what you may have >> thought was going on, namely exhibiting an unintended bug. >> >> > I think that means you're never going to want to do this. >> > It could be it should even be warning or erroring out. >> >> Per the above IRC discussions, self referential data is useful. >> >> That said, Larry's comment above about perhaps outlawing it >> for `my` variables and instead only allowing it for `constant`s is >> the way to go. >> >> > > It isn't really anything to do with "class dependent" behaviour. >> > >> > In which case, the documentation could use some improvement. >> >> I am always supportive of at least discussing improvement of any >> aspect of Raku, especially in response to someone experiencing >> a surprise or confusion. >> >> My comment above was meant to be about `,=`. >> >> The difference in behaviour between arrays and hashes for what >> they do when a list is assigned *is* class dependent behaviour. >> >> > (Actually, saying that some behavior in Raku is class dependent is >> > kind of redundant... it's all class dependent in one way or another.) >> >> Right. But I think *something* needs to be said about how the LHS >> gets to decide what happens when you use `=` based on the class >> of the LHS.. >> >> This is different from what happens with, say, `:=`, where the overall >> behaviour is essentially the same regardless of the class of the LHS. >> >> > > Perhaps more importantly, what improvement do you propose? >> > >> > Well, I just mentioned a few. I always want to see more examples >> > in the docs. >> >> Write them, collaborating with those working on the doc to improve >> it, and I predict your wishes will come true. :) >> >> > What else would you use ,= with besides a hash? >> >> Any data structure / composite class. >> >> > 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. >> >> Exactly. >> >> Hashes autoflatten by default, because that's the only sensible thing to >> do. >> >> Arrays do not, because doing flattening by default makes it awkward to >> build data structures. >> >> ---- >> >> To be clear, imo someone's sense that something isn't right is >> always entirely valid. and usually a useful thing to bring to the >> table to improve both their own understanding and Raku. >> >> What wasn't so clear to me was how best to discuss it, so I've >> ended up writing very dry stuff. I hope that I haven;t sounded >> dismissive, because I am absolutely not intending to do aught >> but encourage you to stay with what you are journeying thru >> in regard to the impact of trying `,=` with an array, and having >> in mind its use with a hash, and figuring out how to improve >> Raku semantics, gists, doc, or whatever else is appropriate, >> >> Much love to all, raiph >