Re: The ,= operator
> > @fib[1, 5, 10..15, 20] > (1 8 (89 144 233 377 610 987) 10946) > ^ > > Why??? As Joe noted in his last email: > remember, back in perl-land the default behavior is to flatten, > in raku ... by default [raku is] oriented toward building up > complex structures like arrays of arrays. So Raku does *not* flatten the `10..15`, yielding the result you see. You may have been thrown by seeing that, with `@fib[1..5]`, the range *is* flattened. That's because of the "single argument rule". This is an important Raku concept. In brief, in contexts that are inherently "listy", not "scalar", Raku takes the view that if it's given a *single* thing that is itself listy, Raku should treat that thing as the list of elements it contains. Whereas, if it's given a list of things, then it just accepts that list as is. Thus `@fib[1..5]` treats the `1..5` as 5 elements, i.e. flattening the range, but treats `@fib[1, 5, 10..15, 20]` as 4 elements, with the third being a nested 6 element list that it does *not* flatten. Perhaps you want the whole lot flattened. Quoting Joe again: > arrays don't flatten unless you do something to make it happen One option: @fib[flat 1, 5, 10..15, 20] > (1 8 89 144 233 377 610 987 10946) love, raiph
Re: The ,= operator
I didn't understood
> my @fib = 1,1, * + * … *;
[...]
> @fib[1]
1
> @fib[5]
8
> @fib[1..5]
(1 2 3 5 8)
*> @fib[1, 5, 10..15, 20](1 8 (89 144 233 377 610 987) 10946)*
* ^*
Why???
On Mon, Dec 7, 2020 at 2:27 AM William Michels via perl6-users <
perl6-users@perl.org> wrote:
>
>
> On Sun, Nov 29, 2020 at 6:38 PM Ralph Mellor
> wrote:
>
>> > Zen slicing as a possible way of 'de-containerizing' :
>> > https://docs.raku.org/language/subscripts#index-entry-Zen_slices
>>
>> A zen-slice only affects the single reference it's applied to.
>>
>> And it is a no op when applied to anything other than a `Scalar`.
>>
>> So it'll have no effect when applied directly to an array, list, hash,
>> or other non `Scalar`.
>>
>> Perhaps you're thinking "decontainerizing" does something other
>> than what it does? It's really a very simple operation. An analogy
>> is having a bunch of folk, some of whom always go by their legal
>> name, but others who sometimes go by their nickname. And let's
>> say there's an operation called "use legal name". When applied
>> to a nickname it yields the corresponding legal name. But when
>> applied to a legal name it just yields that name, i.e. it's a no op.
>>
>> That's all that decont does, except the analog to a nickname is
>> a `Scalar`, and the analog to a legal name is anything else.
>>
>> > 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.
>>
>> I think the focus on `,=`.is really unfortunate, because the real issue is
>> just about what `=` does with a non-`Scalar` on its LHS and a list of
>> values on its RHS. It's really got nothing whatsoever to do with `,`.
>>
>> It just depends on the type of non-`Scalar` on the LHS of `=`.
>>
>> Look what happens without not a comma in sight:
>>
>> my %hash = do for ^1 { %hash }
>> say %hash; # {}
>>
>> If it's a hash,, the only sensible thing to do with a list of values that
>> may
>> each be a pair, or a list of pairs, or an array of pairs, or a hash of
>> pairs,
>> is to flatten and concatenate all the individual pairs into the hash.
>>
>> my @array = do for ^1 { @array }
>> say @array; # (\Array_73652568 = [Array_73652568])
>>
>> But if it's an array, the sensible thing to do is to *not* flatten by
>> default.
>>
>
>
> This topic was a subject of discussion during our (SF_Perl) Raku Meetup
> Group today. We reviewed the three URL references below. One member of our
> Meetup went throught the 2017 Advent Calendar reference extensively
> (hopefully we'll see a post on that). Afterwards, I played a bit with
> indexing constructs. Posting these for posterity's sake:
>
> https://docs.raku.org/language/subscripts#index-entry-Zen_slices
> https://docs.raku.org/language/glossary#index-entry-decont
> https://perl6advent.wordpress.com/2017/12/02/#theoneandonly
>
> user@mbook:~$ raku
> Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
> Implementing the 퐑퐚퐤퐮™ programming language v6.d.
> Built on MoarVM version 2020.10.
>
> You may want to `zef install Readline` or `zef install Linenoise` or use
> rlwrap for a line editor
>
> To exit type 'exit' or '^D'
> > my %hash = do for ^1 { %hash }
> {}
> > my %hash2 = do for ^1 { %hash2<> }
> {}
> > my %hash3 = do for ^1 { %hash3<*> }
> Odd number of elements found where hash initializer expected:
> Only saw 1 element
> in block at line 1
>
> > my @array = do for ^1 { @array }
> (\Array_140587615723064 = [Array_140587615723064])
> > my @array2 = do for ^1 { @array2[] }
> (\Array_140587615723904 = [Array_140587615723904])
> > my @array3 = do for ^1 { @array3[*] }
> [()]
>
> Best Regards, Bill.
>
>
--
Aureliano Guedes
skype: aureliano.guedes
contato: (11) 94292-6110
whatsapp +5511942926110
Re: The ,= operator
On Sun, Nov 29, 2020 at 6:38 PM Ralph Mellor
wrote:
> > Zen slicing as a possible way of 'de-containerizing' :
> > https://docs.raku.org/language/subscripts#index-entry-Zen_slices
>
> A zen-slice only affects the single reference it's applied to.
>
> And it is a no op when applied to anything other than a `Scalar`.
>
> So it'll have no effect when applied directly to an array, list, hash,
> or other non `Scalar`.
>
> Perhaps you're thinking "decontainerizing" does something other
> than what it does? It's really a very simple operation. An analogy
> is having a bunch of folk, some of whom always go by their legal
> name, but others who sometimes go by their nickname. And let's
> say there's an operation called "use legal name". When applied
> to a nickname it yields the corresponding legal name. But when
> applied to a legal name it just yields that name, i.e. it's a no op.
>
> That's all that decont does, except the analog to a nickname is
> a `Scalar`, and the analog to a legal name is anything else.
>
> > 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.
>
> I think the focus on `,=`.is really unfortunate, because the real issue is
> just about what `=` does with a non-`Scalar` on its LHS and a list of
> values on its RHS. It's really got nothing whatsoever to do with `,`.
>
> It just depends on the type of non-`Scalar` on the LHS of `=`.
>
> Look what happens without not a comma in sight:
>
> my %hash = do for ^1 { %hash }
> say %hash; # {}
>
> If it's a hash,, the only sensible thing to do with a list of values that
> may
> each be a pair, or a list of pairs, or an array of pairs, or a hash of
> pairs,
> is to flatten and concatenate all the individual pairs into the hash.
>
> my @array = do for ^1 { @array }
> say @array; # (\Array_73652568 = [Array_73652568])
>
> But if it's an array, the sensible thing to do is to *not* flatten by
> default.
>
This topic was a subject of discussion during our (SF_Perl) Raku Meetup
Group today. We reviewed the three URL references below. One member of our
Meetup went throught the 2017 Advent Calendar reference extensively
(hopefully we'll see a post on that). Afterwards, I played a bit with
indexing constructs. Posting these for posterity's sake:
https://docs.raku.org/language/subscripts#index-entry-Zen_slices
https://docs.raku.org/language/glossary#index-entry-decont
https://perl6advent.wordpress.com/2017/12/02/#theoneandonly
user@mbook:~$ raku
Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2020.10.
You may want to `zef install Readline` or `zef install Linenoise` or use
rlwrap for a line editor
To exit type 'exit' or '^D'
> my %hash = do for ^1 { %hash }
{}
> my %hash2 = do for ^1 { %hash2<> }
{}
> my %hash3 = do for ^1 { %hash3<*> }
Odd number of elements found where hash initializer expected:
Only saw 1 element
in block at line 1
> my @array = do for ^1 { @array }
(\Array_140587615723064 = [Array_140587615723064])
> my @array2 = do for ^1 { @array2[] }
(\Array_140587615723904 = [Array_140587615723904])
> my @array3 = do for ^1 { @array3[*] }
[()]
Best Regards, Bill.
Re: The ,= operator
ToddAndMargo via perl6-users wrote:
> I am a little late to this conversation, but `,=`
> looks a lot like `push` to me.
Yes that was my first impression, if you read ahead a bit in the
discussion you'll see it explained.
In summary: the = shortcuts all work in a precisely parallel way, so
@r ,= 'd';
is the same as:
@r = @r , 'd';
And remember, back in perl-land the default behavior is to flatten,
but in raku arrays don't flatten unless you do something to make it
happen-- by default it's oriented toward building up complex
structures like arrays of arrays. So with this construct, you end up
with the array containing a circular reference to itself in the first
location, which is highly unlikely to be something you want.
Hashes, on the other hand, *don't* tend to flatten by default, so ,=
does something useful with them.
If you wanted to just add an element to the end, you could do one of these:
@r.append('d');
@r = | @r, 'd';
@r.push('d');
The trouble with that last one though, is you may find it surprising
if you're pushing more than a single element, this will get you an
array inside an array:
@r.push(@a);
This on the other hand, behaves just like an @r.append(@a) would:
@r.push(| @a);
Re: The ,= operator
Hi All, I am a little late to this conversation, but `,=` looks a lot like `push` to me. Am I missing something? -T
Re: The ,= operator
William Michels wrote:
> Joe, what would you expect the code below to produce?
> %h<> ,= c => 3;
> @a[] ,= 'd';
Well *I* expect it to error out, but that's my p5 brain talking.
The Raku approach is if you ask for nothing it gives you
everything, so an empty index like that essentially doesn't
change anything.
And in any case, there are limits to how much it's worth
thinking about this case, because there are other ways to do what
I thought ,= would do on an array:
my @a = ;
@a.append('d');
say @a; # [a b c d ]
As Ralph Mellor was suggesting, .append is indeed closer to what I was
thinking than .push.
When you're trying to add multiple elements, the .append method
appends the list to the list in the first array, but .push treats a
given array as a single element, creating a deeper data structure:
my @n = ;
@a.push( @n ); # treats array as a new element
@a.append( @n ); # flattens the array, appends a list
say @a;
# [a b c d e [x y z] x y z]
Re: The ,= operator
> Ralph Mellor wrote: > >> > @r = @r , 'd'; > >> > >> There isn't anything very useful in this behavior though, is there? > > Just to be clear, I wasn't saying I didn't think circular references > should be forbidden, I just specifically meant that you weren't likely > to want the ",=" operator to create them. Ah. OK. My guess is that when they *are* constructed, they're almost always constructed using `=` and `,`. And that would lead to the same result and display that use of `,=` does. After all, the latter is just shorthand for the former. > But then really, I'm not too likely ",=" for appending additional array > elements, I'm more likely to reach for .push. Indeed. (Or .append.) My tentative strawman proposal based on discussion thus far is: * The doc page showing use of `,=` with a hash might benefit from a parenthetical remark that push/append is the right tool to use with positionals rather than `,=` because, unlike associatives, for which flattening is the only sensible semantics, positionals instead default to *not* flattening (so they more easily retain structure, which is what most folk want most of the time). * Liz's "thoughts welcome" is applicable to all things, and in particular to the gist of self-referential data.
Re: The ,= operator
> Zen slicing as a possible way of 'de-containerizing' :
> https://docs.raku.org/language/subscripts#index-entry-Zen_slices
A zen-slice only affects the single reference it's applied to.
And it is a no op when applied to anything other than a `Scalar`.
So it'll have no effect when applied directly to an array, list, hash,
or other non `Scalar`.
Perhaps you're thinking "decontainerizing" does something other
than what it does? It's really a very simple operation. An analogy
is having a bunch of folk, some of whom always go by their legal
name, but others who sometimes go by their nickname. And let's
say there's an operation called "use legal name". When applied
to a nickname it yields the corresponding legal name. But when
applied to a legal name it just yields that name, i.e. it's a no op.
That's all that decont does, except the analog to a nickname is
a `Scalar`, and the analog to a legal name is anything else.
> 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.
I think the focus on `,=`.is really unfortunate, because the real issue is
just about what `=` does with a non-`Scalar` on its LHS and a list of
values on its RHS. It's really got nothing whatsoever to do with `,`.
It just depends on the type of non-`Scalar` on the LHS of `=`.
Look what happens without not a comma in sight:
my %hash = do for ^1 { %hash }
say %hash; # {}
If it's a hash,, the only sensible thing to do with a list of values that may
each be a pair, or a list of pairs, or an array of pairs, or a hash of pairs,
is to flatten and concatenate all the individual pairs into the hash.
my @array = do for ^1 { @array }
say @array; # (\Array_73652568 = [Array_73652568])
But if it's an array, the sensible thing to do is to *not* flatten by default.
Re: The ,= operator
On Sun, Nov 29, 2020 at 9:16 AM Joseph Brenner wrote: > > William Michels 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. > > I think the trouble with ideas like that is once you accept that > > @a ,= 'd'; > > Is necessarily a short-form of: > > @a = @a, 'd'; > > You can see the thing you need to decontainerize is that @a on > the RHS: > > @a = | @a, 'd'; > > But you can't get at it in the short form. > > (So you wouldn't normally try to use the short form with arrays.) Hi Joe, what would you expect the code below to produce? %h<> ,= c => 3; @a[] ,= 'd'; Best, Bill.
Re: The ,= operator
William Michels 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. I think the trouble with ideas like that is once you accept that @a ,= 'd'; Is necessarily a short-form of: @a = @a, 'd'; You can see the thing you need to decontainerize is that @a on the RHS: @a = | @a, 'd'; But you can't get at it in the short form. (So you wouldn't normally try to use the short form with arrays.)
Re: The ,= operator
Joseph Brenner wrote: > Just to be clear, I wasn't saying I didn't think circular references should be forbidden, Sorry about the double-negative. It could use another "not" to triple it.
Re: The ,= operator
Ralph Mellor 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. Just to be clear, I wasn't saying I didn't think circular references should be forbidden, I just specifically meant that you weren't likely to want the ",=" operator to create them. But then really, I'm not too likely ",=" for appending additional array elements, I'm more likely to reach for .push.
Re: The ,= operator
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 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
>> 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
Re: The ,= operator
> > "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 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; # ( [ 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
Re: The ,= operator
> > @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; # ( [ 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
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.
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
@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
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: Match operator: error with any() junction and user-defined $_ topic variable
On 10/12/19 3:08 AM, William Michels via perl6-users wrote: Inline: On Fri, Oct 11, 2019 at 8:33 PM ToddAndMargo via perl6-users wrote: On 10/11/19 8:09 PM, William Michels via perl6-users wrote: Hi Todd, Per the REPL, $x looks to be a List: mbook:~ homedir$ perl6 To exit type 'exit' or '^D' my $x = (44,66) (44 66) say $x.WHAT (List) say $x.^name List my $y = < 55 77 > (55 77) say $y.WHAT (List) say $y.^name List say $*VM moar (2019.07.1) HTH, Bill. HTH, Bill. Sweet. Love examples. Thank you! Question: what type is "my $x = (44, 66)". An array? $ p6 'my List $x = (44,66); say $x;' (44 66) :-) #REPL Below: my $z = 2,4,6,8; (2 4 6 8) say $z.WHAT (Int) say $z.^name Int say $z.List.WHAT (List) say $z.List.^name List With the code above, you might be convinced you've created a $z scalar holding the values (2 4 6 8) that can be coerced to a list whenever you desire. You'd be incorrect though: my $z = 2,4,6,8; (2 4 6 8) say $z 2 say $z.WHAT (Int) say $z.elems 1 my $a = (2,4,6,8); (2 4 6 8) say $a (2 4 6 8) say $a.WHAT (List) say $a.elems 4 say $*VM moar (2019.07.1) I guess parentheses are important in Perl 6. Some references here (may be in need of updating): https://docs.perl6.org/language/list https://stackoverflow.com/questions/34997353/what-type-are-lists-of-any-type-in-perl-6 https://stackoverflow.com/questions/34997670/how-is-this-perl-sensical-considering-perl-6s-type-system HTH, Bill. Thank you! -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~
Re: Match operator: error with any() junction and user-defined $_ topic variable
Inline: On Fri, Oct 11, 2019 at 8:33 PM ToddAndMargo via perl6-users wrote: > > On 10/11/19 8:09 PM, William Michels via perl6-users wrote: > > Hi Todd, Per the REPL, $x looks to be a List: > > > > mbook:~ homedir$ perl6 > > To exit type 'exit' or '^D' > >> > >> my $x = (44,66) > > (44 66) > >> say $x.WHAT > > (List) > >> say $x.^name > > List > >> > >> my $y = < 55 77 > > > (55 77) > >> say $y.WHAT > > (List) > >> say $y.^name > > List > >> > >> say $*VM > > moar (2019.07.1) > > > > HTH, Bill. > > > > > > >>> HTH, Bill. > >> > >> Sweet. Love examples. Thank you! > >> > >> Question: what type is "my $x = (44, 66)". An array? > > > $ p6 'my List $x = (44,66); say $x;' > (44 66) > > :-) > #REPL Below: > my $z = 2,4,6,8; (2 4 6 8) > say $z.WHAT (Int) > say $z.^name Int > say $z.List.WHAT (List) > say $z.List.^name List > With the code above, you might be convinced you've created a $z scalar holding the values (2 4 6 8) that can be coerced to a list whenever you desire. You'd be incorrect though: > my $z = 2,4,6,8; (2 4 6 8) > say $z 2 > say $z.WHAT (Int) > say $z.elems 1 > my $a = (2,4,6,8); (2 4 6 8) > say $a (2 4 6 8) > say $a.WHAT (List) > say $a.elems 4 > say $*VM > moar (2019.07.1) I guess parentheses are important in Perl 6. Some references here (may be in need of updating): https://docs.perl6.org/language/list https://stackoverflow.com/questions/34997353/what-type-are-lists-of-any-type-in-perl-6 https://stackoverflow.com/questions/34997670/how-is-this-perl-sensical-considering-perl-6s-type-system HTH, Bill.
Re: Match operator: error with any() junction and user-defined $_ topic variable
On 10/11/19 8:09 PM, William Michels via perl6-users wrote: Hi Todd, Per the REPL, $x looks to be a List: mbook:~ homedir$ perl6 To exit type 'exit' or '^D' my $x = (44,66) (44 66) say $x.WHAT (List) say $x.^name List my $y = < 55 77 > (55 77) say $y.WHAT (List) say $y.^name List say $*VM moar (2019.07.1) HTH, Bill. HTH, Bill. Sweet. Love examples. Thank you! Question: what type is "my $x = (44, 66)". An array? $ p6 'my List $x = (44,66); say $x;' (44 66) :-) -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~
Re: Match operator: error with any() junction and user-defined $_ topic variable
Hi Todd, Per the REPL, $x looks to be a List: mbook:~ homedir$ perl6 To exit type 'exit' or '^D' > > my $x = (44,66) (44 66) > say $x.WHAT (List) > say $x.^name List > > my $y = < 55 77 > (55 77) > say $y.WHAT (List) > say $y.^name List > > say $*VM moar (2019.07.1) HTH, Bill. On Fri, Oct 11, 2019 at 4:24 PM ToddAndMargo via perl6-users wrote: > > On 10/11/19 2:46 AM, William Michels via perl6-users wrote: > > Below works: > > > > mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 43' > > (44 66) > > any(False, False) > > # > > mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 50' > > (44 66) > > any(True, False) > > # > > mbook:~ homedir$ perl6 -e 'my $x=0; my $any=2|4|8; $x==$any ?? put "x > > exists, value= $x" !! put "not there";' > > not there > > # > > mbook:~ homedir$ perl6 -e 'my $x=4; my $any=2|4|8; $x==$any ?? put "x > > exists, value= $x" !! put "not there";' > > x exists, value= 4 > > # > > > > HTH, Bill. > > Sweet. Love examples. Thank you! > > Question: what type is "my $x = (44, 66)". An array?
Re: Match operator: error with any() junction and user-defined $_ topic variable
On 10/11/19 2:46 AM, William Michels via perl6-users wrote: Below works: mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 43' (44 66) any(False, False) # mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 50' (44 66) any(True, False) # mbook:~ homedir$ perl6 -e 'my $x=0; my $any=2|4|8; $x==$any ?? put "x exists, value= $x" !! put "not there";' not there # mbook:~ homedir$ perl6 -e 'my $x=4; my $any=2|4|8; $x==$any ?? put "x exists, value= $x" !! put "not there";' x exists, value= 4 # HTH, Bill. Sweet. Love examples. Thank you! Question: what type is "my $x = (44, 66)". An array?
Re: Match operator: error with any() junction and user-defined $_ topic variable
Below works: mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 43' (44 66) any(False, False) # mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 50' (44 66) any(True, False) # mbook:~ homedir$ perl6 -e 'my $x=0; my $any=2|4|8; $x==$any ?? put "x exists, value= $x" !! put "not there";' not there # mbook:~ homedir$ perl6 -e 'my $x=4; my $any=2|4|8; $x==$any ?? put "x exists, value= $x" !! put "not there";' x exists, value= 4 # HTH, Bill. On Thu, Oct 10, 2019 at 9:30 PM Todd Chester via perl6-users wrote: > > > > On 10/8/19 10:53 AM, Brad Gilbert wrote: > > Most operations with Junctions produce Junctions. > > > > > 1 + any(2, 3) > > any(3, 4) > > $ p6 'say 4 + any(44,66);' > any(48, 70) > > Sweet! But what would you ever use it for? > > Would this be the intended use: add a number to all > values in an array? > > $ p6 'my @x=[44,66]; say 4 + @x.any;' > any(48, 70) > > $ p6 'my @x=[44,66]; 4 + @x.any; say @x' > WARNINGS for -e: > Useless use of "+" in expression "4 + @x.any" in sink context (line 1) > [44 66] > > > -T
Re: Match operator: error with any() junction and user-defined $_ topic variable
On 10/8/19 10:53 AM, Brad Gilbert wrote: Most operations with Junctions produce Junctions. > 1 + any(2, 3) any(3, 4) $ p6 'say 4 + any(44,66);' any(48, 70) Sweet! But what would you ever use it for? Would this be the intended use: add a number to all values in an array? $ p6 'my @x=[44,66]; say 4 + @x.any;' any(48, 70) $ p6 'my @x=[44,66]; 4 + @x.any; say @x' WARNINGS for -e: Useless use of "+" in expression "4 + @x.any" in sink context (line 1) [44 66] -T
Re: Match operator: error with any() junction and user-defined $_ topic variable
Thank you very much Brad!!
Let's redirect all conversation on this particular issue here:
https://github.com/rakudo/rakudo/issues/3221
Best Regards, Bill.
On Tue, Oct 8, 2019 at 10:53 AM Brad Gilbert wrote:
>
> Most operations with Junctions produce Junctions.
>
> > 1 + any(2, 3)
> any(3, 4)
>
> > any(1, 2) + 3
> any(4, 5)
>
> > any() ~~ /./
> any(｢a｣, ｢c｣)
>
> In the case of the following line, `$/` gets assigned a junction of the
> results.
>
> > if any(@genus) ~~ m/Hama/ { put "Matches at least one again"; };
>
> The `m/Hama/` is executing early in the smartmatch `~~`.
> Really you should have been using `rx/Hama/` or `/Hama/` instead.
>
> > any() ~~ m/./
> False
>
> `m//` always executes against `$_`. While `rx//` always evaluates to the
> regex itself.
> (`/…/` will do one or the other depending on context.)
> So there are some places where `m//` appears to wait to execute like the
> following line.
>
> > 'abc' ~~ m/b/
>
> It doesn't wait. It executes immediately.
>
>
> The reason is that smartmatch is actually a two step process.
> The above example is basically short for the following line:
>
> > (do given 'abc' { m/b/ }).ACCEPTS('abc')
>
> Now I am going to simplify it.
> The `m/b/` executes immediately.
>
> > (do given 'abc' { ｢b｣ }).ACCEPTS('abc')
> > ( ｢b｣ ).ACCEPTS('abc')
>
> Since `.ACCEPTS` on an instance of Match always returns itself, the above
> returns the Match object.
>
> It would operate differently, but come to the same result with `rx//`.
>
> > (do given 'abc' { rx/b/ }).ACCEPTS('abc')
> > ( rx/b/ ).ACCEPTS('abc')
>
> Since `rx/b/` does indeed accept 'abc' the end result of the above line is
> the Match object ｢b｣.
>
>
> In the case of a Junction, the `~~` applies to each part of the junction
> separately, and then combines the results.
> So `$/` gets assigned a Junction rather than the normal Match.
> (Which means `m//` and `rx//` do not come to the same result.)
>
> If the book says that `@genus ~~ m/Hama/` and `any(@genus) ~~ m/Hama/` are
> exactly the same, it is incorrect.
> The first sets $/ and returns the first value that returns a True value.
> While the second returns True and sets $/ to a Junction of all the results.
>
>
> Then later when you do just `m//` it tries to assign to each value in the
> Junction to the new result.
> Since the junction contains immutable values, that doesn't work.
>
> > $_ = 'abc';
> > $/ = any 'def', 'ghi';
> > m/abc/
> Cannot modify an immutable Str (def)
> in block at line 1
>
> Basically when `m//` tries to do `$/ = …` it threads through the Junction
> rather than just assigning directly to `$/`.
> It is a bug in the assignment code that m// uses.
>
>
> When submitting a bug report, it is best to reduce the problem to the
> simplest example that still produces the error. The last example here does
> just that.
> This is a compiler / runtime issue. The compiler's name is Rakudo, so the
> appropriate repository would be https://github.com/rakudo/rakudo.
> Since you found the issue, I think you should create the issue in the bug
> tracker.
> (Mainly because that is a common first stepping stone to getting involved.)
>
>
>
> On Tue, Oct 8, 2019 at 2:53 AM William Michels via perl6-users
> wrote:
>>
>> Greetings:
>>
>> I tried the following regular expression code, working generally from
>> "Learning Perl 6" by brian d foy (Chapter 15). Everything works fine
>> including the any() junction below, as long as the topic $_ variable
>> isn't defined beforehand. However specifically in combination with a
>> user-defined $_ topic variable, an any() junction returns the error,
>> "Cannot modify an immutable Match." See Perl6 REPL code below (also
>> checked with 6Pad (https://perl6.github.io/6pad/)) :
>>
>> mbook:~ homedir$ perl6
>> To exit type 'exit' or '^D'
>> > $_ = 'Hamadryas';
>> Hamadryas
>> > my @genus = < Hamadryas Sostrata Junonia >;
>> [Hamadryas Sostrata Junonia]
>> > say $_.WHAT, $/.WHAT;
>> (Str)Nil
>> > if @genus ~~ m/Hama/ { put "Matches at least one"; };
>> Matches at least one
>> > say $_.WHAT, $/.WHAT;
>> (Str)(Match)
>> > say m/Hama/;
>> ｢Hama｣
>> > say m/Hama/;
>> ｢Hama｣
>> > say $_.WHAT, $/.WHAT;
>> (Str)(Match)
>> > if any(@genus) ~~ m/Hama/ { put "Matches at least one again"; };
>> Matches at least one again
>> > say $_.WHAT, $/.WHAT;
>> (Str)(Junction)
>> > say m/Hama/;
>> Cannot modify an immutable Match (｢Hama｣)
>> in block at line 1
>>
>> > say $*VM
>> moar (2019.07.1)
>> >
>>
>> I understood from the "Learning Perl 6" book that the two smart-match
>> lines of code are equivalent--the first one simply understands that
>> there is an 'implied' any() junction to check the array against the
>> match operator. But REPL reports back that in one case $/ returns a
>> match object type, while in the other case [with an explicit any()
>> junction], $/ returns a junction object type. So this
Re: Match operator: error with any() junction and user-defined $_ topic variable
Most operations with Junctions produce Junctions.
> 1 + any(2, 3)
any(3, 4)
> any(1, 2) + 3
any(4, 5)
> any() ~~ /./
any(｢a｣, ｢c｣)
In the case of the following line, `$/` gets assigned a junction of the
results.
> if any(@genus) ~~ m/Hama/ { put "Matches at least one again"; };
The `m/Hama/` is executing early in the smartmatch `~~`.
Really you should have been using `rx/Hama/` or `/Hama/` instead.
> any() ~~ m/./
False
`m//` always executes against `$_`. While `rx//` always evaluates to the
regex itself.
(`/…/` will do one or the other depending on context.)
So there are some places where `m//` appears to wait to execute like the
following line.
> 'abc' ~~ m/b/
It doesn't wait. It executes immediately.
The reason is that smartmatch is actually a two step process.
The above example is basically short for the following line:
> (do given 'abc' { m/b/ }).ACCEPTS('abc')
Now I am going to simplify it.
The `m/b/` executes immediately.
> (do given 'abc' { ｢b｣ }).ACCEPTS('abc')
> ( ｢b｣ ).ACCEPTS('abc')
Since `.ACCEPTS` on an instance of Match always returns itself, the above
returns the Match object.
It would operate differently, but come to the same result with `rx//`.
> (do given 'abc' { rx/b/ }).ACCEPTS('abc')
> ( rx/b/ ).ACCEPTS('abc')
Since `rx/b/` does indeed accept 'abc' the end result of the above line is
the Match object ｢b｣.
In the case of a Junction, the `~~` applies to each part of the junction
separately, and then combines the results.
So `$/` gets assigned a Junction rather than the normal Match.
(Which means `m//` and `rx//` do not come to the same result.)
If the book says that `@genus ~~ m/Hama/` and `any(@genus) ~~ m/Hama/` are
exactly the same, it is incorrect.
The first sets $/ and returns the first value that returns a True value.
While the second returns True and sets $/ to a Junction of all the results.
Then later when you do just `m//` it tries to assign to each value in the
Junction to the new result.
Since the junction contains immutable values, that doesn't work.
> $_ = 'abc';
> $/ = any 'def', 'ghi';
> m/abc/
Cannot modify an immutable Str (def)
in block at line 1
Basically when `m//` tries to do `$/ = …` it threads through the Junction
rather than just assigning directly to `$/`.
It is a bug in the assignment code that m// uses.
When submitting a bug report, it is best to reduce the problem to the
simplest example that still produces the error. The last example here does
just that.
This is a compiler / runtime issue. The compiler's name is Rakudo, so the
appropriate repository would be https://github.com/rakudo/rakudo.
Since you found the issue, I think you should create the issue in the bug
tracker.
(Mainly because that is a common first stepping stone to getting involved.)
On Tue, Oct 8, 2019 at 2:53 AM William Michels via perl6-users <
perl6-users@perl.org> wrote:
> Greetings:
>
> I tried the following regular expression code, working generally from
> "Learning Perl 6" by brian d foy (Chapter 15). Everything works fine
> including the any() junction below, as long as the topic $_ variable
> isn't defined beforehand. However specifically in combination with a
> user-defined $_ topic variable, an any() junction returns the error,
> "Cannot modify an immutable Match." See Perl6 REPL code below (also
> checked with 6Pad (https://perl6.github.io/6pad/)) :
>
> mbook:~ homedir$ perl6
> To exit type 'exit' or '^D'
> > $_ = 'Hamadryas';
> Hamadryas
> > my @genus = < Hamadryas Sostrata Junonia >;
> [Hamadryas Sostrata Junonia]
> > say $_.WHAT, $/.WHAT;
> (Str)Nil
> > if @genus ~~ m/Hama/ { put "Matches at least one"; };
> Matches at least one
> > say $_.WHAT, $/.WHAT;
> (Str)(Match)
> > say m/Hama/;
> ｢Hama｣
> > say m/Hama/;
> ｢Hama｣
> > say $_.WHAT, $/.WHAT;
> (Str)(Match)
> > if any(@genus) ~~ m/Hama/ { put "Matches at least one again"; };
> Matches at least one again
> > say $_.WHAT, $/.WHAT;
> (Str)(Junction)
> > say m/Hama/;
> Cannot modify an immutable Match (｢Hama｣)
> in block at line 1
>
> > say $*VM
> moar (2019.07.1)
> >
>
> I understood from the "Learning Perl 6" book that the two smart-match
> lines of code are equivalent--the first one simply understands that
> there is an 'implied' any() junction to check the array against the
> match operator. But REPL reports back that in one case $/ returns a
> match object type, while in the other case [with an explicit any()
> junction], $/ returns a junction object type. So this feels
> inconsistent, at the very least.
>
> Any explanation appreciated. If after triaging this issue, someone
> would like me to open a Github issue, please point me towards the
> correct repository.
>
> Thanks, Bill.
>
> W. Michels, Ph.D.
>
Re: xx operator
I have the following code:
class MyStupidString {
method repeatit(Str $string, Int $repeat) {
say $string xx $repeat;
my $add = $string xx $repeat;
say $add;
}
};
my $obj = MyStupidString.new;
$obj.repeatit(---,10);
Interestingly, it says:
pugs test2.p6
--
--- --- --- --- --- --- --- --- --- ---
What am I misunderstanding here?
The `xx` operator. That's list-repeat, not string-repeat.
In Perl 5 terms, the code you wrote is:
sub repeatit {
my ( $string, $repeat ) = @_;
my @res = ( $string ) x $repeat;
print @res;
my $add = @res;
print $add;
}
which should make it obvious what is going on.
--
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
Re: xx operator
Fagyal Csongor skribis 2006-09-28 15:11 (+0200): say $string xx $repeat; List context. my $add = $string xx $repeat; Item context, for a list repetition operator. Doesn't really make sense, and I think a warning or error message would be more appropriate. I think you meant either: my @add = $string xx $repeat; or: my $add = $string x $repeat; Or perhaps: my $add = [ $string xx $repeat ]; # This is what your current code does, but I think it's best if Perl # enforced that you be explicit about the []. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
