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-us...@perl.org> wrote: > > > On Sun, Nov 29, 2020 at 6:38 PM Ralph Mellor <ralphdjmel...@gmail.com> > 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 <unit> at <unknown file> 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