Front page | perl.perl5.porters |
Postings from February 2022
Re: PSC #054 2022-02-11
From: Oodler 577 via perl5-porters
February 15, 2022 17:58
Re: PSC #054 2022-02-11
Message ID: Ygvph75hDcg8jOVC@odin.sdf-eu.org
* Ricardo Signes <email@example.com> [2022-02-15 12:30:31 -0500]:
> The gang was all here: Neil, Paul, Rik.
> We discussed a few RFCs.
> The ?configure option to disable taint? RFC had a couple questions we thought were resolved: how do we phrase the question in Configure (where the ?not? goes!), and whether trying to use taint mode on a no-taint-mode perl is fatal. These were resolved and the RFC PR was merged.
> The ?kv? proposal meant to help get index/value pairs of arrays for two-at-a-time iteration was up next. We closed it. I?m going to write up a new RFC for something like `indexed(@arr)`
This is good news and slightly disappointing. I was actually
excited about a "kv" when I thought it operated over pairs.
E.g., I mistakenly thought that:
1. for %hashes, it'd iterate pairwise returning the
actual ($key, $value)
2. for @arrays, it'd do the same - provide every 2
elements of the array;
In fact, I was quite confused because "kv" implies what
I describe above, not something that returned an index/element
for arrays - though, I agree this is helpful.
My thought was:
* kv - would operate over %hashes and @arrays, as described above
* iv ("indexed", above) - (I know, overloaded term), would operate
over @arrays (and maybe unfortunately, %hashes) by returning ($index, $element)
This also got me thinking about "zip" operations, which are inverse
of what "kv" is; given 2 arrays, say @KEYS and @VALUES; "zip" would
produce the pairing that results in a hash. I'm staying away from
overgeneralizing to >1 demensions and don't recommend we "go there"
any more than we already do. Anyway, e.g.,
my @KEYS = (qw/foo bar baz/);
my @VALUES = (qw/herp derp whatever/);
my %hash = zip \@KEYS, \@VALUES;
# %hash would be,
foo => 'herp',
bar => 'derp',
baz => 'whatever',
So "kv" would be the "unzip" (inverse) to the "zip"
described above. And "zip" is basically an interleave
operator that pairs like indexes of each "array" or list.
If this is attractive (I'm personally excited about it),
I'd be happy to write up a pre-RFC for it.
FWIW, the "Chapel" (aka ZPL) language has similar list operators,
though they have much more precise controls. I don't think
we'd need anything other than what's described above to find
zip/unzip - or interleave/kv - operators useful.
> Ovid?s ?modules? RFC PR was closed.
> We talked about signatures.
> There was a lot of discussion, here, but the big takeaway was that we all agree that signatures should be removed from experimental status, except for the use of `@_` inside a signatured sub, which gets an experimental warning, and which we think will surely change, given the significant speed-ups we expect can be wrung out of it.
> Further, they should be enabled under `use v5.36`, as part of our goal of providing the best possible perl we can with the least required boilerplate.
> We also want to make sure it?s clearly document, not only for general use, but that our documentation shows Perl being written in an up-to-date way. Once the general code freeze is in place, we?re hoping to make a pass through our docs to get them all up to date.
> Karl has been doing some work on source::encoding ? namely, making it work! Apart from making it work, our big question was whether we could feel good about making `use v5.36` imply `use source::encoding 'ascii'`, and the general consensus was, ?yes, if we feel good about its tests.? I have begun making a modest pass at some tests, but definitely need to set aside some time for being a bit more aggressive in my approach.
> I?ll also be following up with Dan Kogai to make `use encoding` always fatal on new Perls.
> Bidirectional bracketing pairs
> We at least agreed that this isn?t going into the v5.36 feature bundle. The big question here is ?can we curate a set of brackets such that they?re not problematically surprising.? So far, I think Karl is on the right track, but it needs some discussion.
> I?d like to get through a bunch more experiments, as I think a few more can yet be removed from experimental status, but we were running out of time. We only covered one: `isa`. On our call as p5p, there is general agreement that the `isa` operator can be removed from experimental status.
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native