P.S. My apologies for top-posting in the quoted text, and my apologies
to William for the duplication.
On 11/29/20, Parrot Raiser <1parr...@gmail.com> wrote:
> 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
>>
>
