The colon only works on a method call. In "say sort:" it's not used as a
method, it's used as a sub; the colon causes it to try to reinterpret as a
method call, then it can't find an invocant for the method to operate on.

In "@x .= sort:", the ".=" forces a method call with @x as invocant; then
"sort:" has an invocant to work with.

On Sat, Jun 9, 2018 at 4:02 PM Xin Cheng <xinchen...@gmail.com> wrote:

> Thanks. But I am actually confused by the use of colon in
>
> Sort: { ... }
>
> What does it mean in the above statement? I have done several experiments
> like:
>
> p6 'say sort({$^a <=> $^b}, < 3 5 2 1>)'        # (1 2 3 5)
>
> p6 'say <3 5 2 1>.sort({$^a <=> $^b})'         # it works.
>
> p6 'say <3 5 2 1>.sort: {$^a <=> $^b}'          # it works.
>
> But I don't know what the colon here mean, although I know it works.
>
> If I write something like this,
>
> p6 'say sort: {$^a <=> $^b} < 3 5 2 1> '      # It doesn't work.
>
> But why? Why the colon works in one form, but not in another form? So I
> want to know the meaning of the colon when it works.
>
> Regards
>
> Xin
>
> On Jun 9, 2018, at 3:01 PM, Brandon Allbery <allber...@gmail.com> wrote:
>
> The ".=" operator means call the method on the right, with the thing on
> the left as invocant, and assign the result back to the thing on the left.
> So
>
>     @x .= sort: ...
>
> is the same as
>
>     @x = @x.sort(...)
>
> So you're being confused by the syntactic "magic" of ".=".
>
> On Sat, Jun 9, 2018 at 2:58 PM Xin Cheng <xinchen...@gmail.com> wrote:
>
>> I got the point for //.
>>
>> Another question is about calling the method sort with a code block. I
>> can understand
>>
>> @x .= sort({ ... });
>>
>> But I don't quite understand why this form also works.
>>
>> @x .= sort: { ... };
>>
>> I look into the documentation for infix ":",
>> https://docs.perl6.org/routine/: , and it explains something like this:
>>
>> Used as an argument separator just like infix , and marks the argument to
>> its left as the invocant. That turns what would otherwise be a function
>> call into a method call.
>>
>> substr('abc': 1);       # same as 'abc'.substr(1)
>> Infix : is only allowed after the first argument of a non-method call. In
>> other positions, it's a syntax error.
>>
>>
>> How does the above explanation related to the case in hand @x .= sort: {
>> ... }; ? Is sort an invocant? Or I miss something.
>>
>> Regards
>>
>> Xin
>>
>>
>>
>> On Jun 9, 2018, at 12:44 PM, Brandon Allbery <allber...@gmail.com> wrote:
>>
>> More precisely, at that point you have a bunch of numbers, but possibly
>> not as many as expected if some of the components weren't numeric (or all
>> of them, as when there are files present that aren't the expected logs).
>> Which means some or all of those variables will be undefined instead of
>> numbers. The // replaces those with the following value (0), so they do
>> something sensible when sorted instead of producing warnings.
>>
>> On Sat, Jun 9, 2018 at 11:40 AM Xin Cheng <xinchen...@gmail.com> wrote:
>>
>>> This is very interesting. But I wonder how it works. I can understand
>>> the first line
>>>
>>>  my ($month, $day, $year, $hour, $minute, $second) = .comb(/\d+/);
>>>
>>> Which extract the variables from $_. What is the second line doing, it
>>> is very concise.
>>>
>>>  ($year // 0, $month // 0, $day // 0, $hour // 0, $minute // 0,
>>> $second // 0, $_);
>>>
>>> Could somebody explain in some more words.? What does  // do? Why it
>>> sorts the array?
>>>
>>> Regards
>>>
>>> Xin
>>>
>>> On Jun 9, 2018, at 12:51 AM, Timo Paulssen <t...@wakelift.de> wrote:
>>>
>>> That's unnecessarily long and complicated, here's how you can do it much
>>> easier:
>>>
>>>     @x.sort: {
>>>         my ($month, $day, $year, $hour, $minute, $second) = .comb(/\d+/);
>>>         ($year // 0, $month // 0, $day // 0, $hour // 0, $minute // 0,
>>> $second // 0, $_);
>>>     }
>>>
>>> Trying it on some input data:
>>>
>>>     cimtrak.log.06-08-2018_16:07:39.zip
>>>     cimtrak.log.06-08-2018_17:07:39.zip
>>>     cimtrak.log.07-08-2018_06:07:39.zip
>>>     cimtrak.log.07-08-2018_16:07:39.zip
>>>     cimtrak.log.12-08-2016_06:07:39.zip
>>>     cookies
>>>     asbestos
>>>     fire engine
>>>     perl6
>>>     butterflies
>>>
>>> results in:
>>>
>>>     asbestos
>>>     butterflies
>>>     cookies
>>>     fire engine
>>>     perl6
>>>     cimtrak.log.12-08-2016_06:07:39.zip
>>>     cimtrak.log.06-08-2018_16:07:39.zip
>>>     cimtrak.log.06-08-2018_17:07:39.zip
>>>     cimtrak.log.07-08-2018_06:07:39.zip
>>>     cimtrak.log.07-08-2018_16:07:39.zip
>>>
>>> This is the schwartzian transform that was mentioned in another mail.
>>> why it wasn't actually shown, i have no clue :)
>>>
>>> Hope that helps
>>>   - Timo
>>>
>>>
>>>
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>>
>>
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
>
>

-- 
brandon s allbery kf8nh                               sine nomine associates
allber...@gmail.com                                  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

Reply via email to