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-users@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
>
