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 
> <mailto: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/: 
> <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 
>> <mailto: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 
>> <mailto: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 
>>> <mailto: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 <mailto:allber...@gmail.com>                             
>>      ballb...@sinenomine.net <mailto:ballb...@sinenomine.net>
>> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net 
>> <http://sinenomine.net/>
> 
> 
> -- 
> brandon s allbery kf8nh                               sine nomine associates
> allber...@gmail.com <mailto:allber...@gmail.com>                              
>     ballb...@sinenomine.net <mailto:ballb...@sinenomine.net>
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net 
> <http://sinenomine.net/>

Reply via email to