5 ms·
I'm not sure if I've nailed what the GP was speaking of or what you're looking for but anyway I do think the following is illustrative of the linguistic evoluti
by raiph 8y ago
I'm not sure if I've nailed what the GP was speaking of or what you're looking for but anyway I do think the following is illustrative of the linguistic evolution P6 represents.
Earlier this year at perlmonks (perhaps the top resource along with stackoverflow for experienced perl folk answering questions) a poster wanted solutions to a fairly basic operation:[1]
> I need a function which will filter a nested hash, removing any fields I'm not interested in.
Their test data had a source that began:
my $source = {
f1 => 'garbage',
f2 => 'more garbage',
f3 => 'important data',
f4 => {
this => 'sub hash',
is => 'garbage'
},
f5 => {
f6 => 'more important data',
and a filter that began:
my $filter = {
f3 => 1,
f5 => {
f6 => 1,
After a few days the person who asked the question summarized the community's P5 answers.[2]
The first one listed (slightly trimmed):
#! /usr/bin/env perl
use strict;
use warnings;
use Carp;
use Deep::Hash::Utils qw(reach nest deepvalue);
sub hash_filter_recursive {
my $source = shift;
my $filter = shift;
my %output;
foreach ( keys %$filter ) {
if ( exists $source->{$_} ) {
if ( ref $filter->{$_} eq 'HASH' ) {
croak "bad filter: on '$_', expected HASH\n"
unless ( ref $source->{$_} eq 'HASH' );
$output{$_} = hash_filter_recursive( $source->{$_}, $filter->{$_} );
}
else {
$output{$_} = $source->{$_};
}
}
}
return \%output;
}
(This appears to include a modicum of input validation.)
Here was my P6 answer, including the call to invoke the routine (which I omitted from the P5):[3]
sub infix:<landr> ($l, $r) { $l and $r };
say $filter «landr» $source
Even though this uses a parallel operation which will one day optionally be automatically mapped to multiple cores to run faster, I'm pretty sure this is currently slower than the P5 solutions.
And I didn't bother with any validation that it was indeed being passed a nested hash.
But it makes a point. While P6 can typically do similar things to P5, it often turns out easier to do many things at a much higher level, which leads to less spaghetti.
----
[1] https://www.perlmonks.org/?node_id=1215517 https://www.perlmonks.org/?node_id=1215517
[2] https://www.perlmonks.org/?node_id=1215736 https://www.perlmonks.org/?node_id=1215736
[3] https://www.perlmonks.org/?node_id=1216274 https://www.perlmonks.org/?node_id=1216274
- vram22 8y agoThanks for the reply. Definitely looks like P6 can work at a higher level ...
- raiph 8y agoYou're welcome. Here's another quick example. It may or may not touch on your or the GGGP's point. So, no need to reply. I just thought I'd post something more while we wait for their reply. say now - INIT now This displays the time difference between the normal run-time moment that the `now` call before the minus is called and the `now` call after the minus sign which is run during the earlier INIT phase of execution: https://docs.perl6.org/language/phasers#phasers__INIT https://docs.perl6.org/language/phasers#phasers__INIT In P5, phased code didn't return values so one needed to create a variable and initialize it elsewhere in the code. P6 has many more phasers than P5 and allows many of them to return values to code that's run at a different phase. (This is sometimes called "time traveling" code.) This saves a lot of jumping back and forth needed to understand a fragment of code.
- vram22 8y ago>You're welcome. Here's another quick example. It may or may not touch on your or the GGGP's point. So, no need to reply. I'll reply anyway, to say thanks again :) I'll admit that I'm a bit phased by P6 phasers :) Had come across them just recently in the docs, initially thought, on a brief look, that at least the ENTER and LEAVE phasers were something like Python's __enter__ and __exit__ special methods used with context managers / "with" statements, or a way of wrapping a function call (or statement) in pre- and post-function invocations. which can be done with decorators in Python. But it seems like phasers may be something more, if not different. Also, there are many other kinds. Need to look into it some, including the "time traveling" code part.
- raiph 8y ago> I'll admit that I'm a bit phased by P6 phasers :) .oO ( a pun set to stun? ) > ENTER and LEAVE ... like Python's __enter__ and __exit__ Aiui their primary usage involves similar use-cases and sugar. The common aspect is that some code is declared and then the language/compiler calls that code when the time is right. > But it seems like phasers may be something more, if not different. Aiui P6: * Has more of these hooks for block processing (eg PRE and POST for convenient pre and post condition assertions); * Has hooks that aren't for blocks but instead much larger scale phases of program execution (eg there's CHECK which runs at the end of compilation, before running the program). Also... > Need to look into it some, including the "time traveling" code part. What I meant by "time traveling" is as follows. The compiler calls phased code when the times is right. Some of the time this is implicit. For example, in this Python code the __exit__ code gets called automatically by the Python interpreter as the block is exited: with foo as bar: qux P6 phases can return values as follows: say now - CHECK now the first `now` happens during regular run time. But the second happens during CHECK time -- which is at the end of compilation, before the program starts to run. The compiler knows to run the CHECK code earlier, then store the result, then subtract that from the `now` run at normal run-time. I don't recall who first called that time traveling and I'm not even sure on reflection whether it makes sense to call it that but that's what I meant.