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

Reply via email to