Mailing List Archive

Elevator pitch - "assuming"
I frequently find myself writing lines of code like the following

$row->{nested}{key} = mutate_it($row->{nested}{key}) if $row->{nested}{key}

And I find it annoying that I have to keep repeating the name of the
variable. The line processes a value if it's truthy, and leaving it falsy
otherwise.

it would be nice if we had a conditional statement that would also
topicalize, so that it could be cut down to
$_ = mutate_it($_) assuming $row->{nested}{key}

Open questions that come to mind is what conditions other than truthiness
would look like. Something like assuming $row->{nested}{key} : exists $_
perhaps?

In terms of what the argument to assuming would be, I guess any lvalue
would make sense.

Existing options:
There is a &&= operator, but it would still require duplication of lengthy
unravelings.
Re: Elevator pitch - "assuming" [ In reply to ]
$_ = mutate_it($_) for $row->{nested}{key}

On Tue, Jul 27, 2021 at 6:34 PM, Veesh Goldman <rabbiveesh@gmail.com> wrote:

> I frequently find myself writing lines of code like the following
>
> $row->{nested}{key} = mutate_it($row->{nested}{key}) if $row->{nested}{key}
>
> And I find it annoying that I have to keep repeating the name of the variable. The line processes a value if it's truthy, and leaving it falsy otherwise.
>
> it would be nice if we had a conditional statement that would also topicalize, so that it could be cut down to
> $_ = mutate_it($_) assuming $row->{nested}{key}
>
> Open questions that come to mind is what conditions other than truthiness would look like. Something like assuming $row->{nested}{key} : exists $_ perhaps?
>
> In terms of what the argument to assuming would be, I guess any lvalue would make sense.
>
> Existing options:
> There is a &&= operator, but it would still require duplication of lengthy unravelings.
Re: Elevator pitch - "assuming" [ In reply to ]
Sorry, I see you wanted a conditional there too.

$_ = mutate_it($_) for grep {$_} $row->{nested}{key}

On Tue, Jul 27, 2021 at 6:44 PM, Mark Gardner <mjg@phoenixtrap.com> wrote:

> $_ = mutate_it($_) for $row->{nested}{key}
>
> On Tue, Jul 27, 2021 at 6:34 PM, Veesh Goldman <rabbiveesh@gmail.com> wrote:
>
>> I frequently find myself writing lines of code like the following
>>
>> $row->{nested}{key} = mutate_it($row->{nested}{key}) if $row->{nested}{key}
>>
>> And I find it annoying that I have to keep repeating the name of the variable. The line processes a value if it's truthy, and leaving it falsy otherwise.
>>
>> it would be nice if we had a conditional statement that would also topicalize, so that it could be cut down to
>> $_ = mutate_it($_) assuming $row->{nested}{key}
>>
>> Open questions that come to mind is what conditions other than truthiness would look like. Something like assuming $row->{nested}{key} : exists $_ perhaps?
>>
>> In terms of what the argument to assuming would be, I guess any lvalue would make sense.
>>
>> Existing options:
>> There is a &&= operator, but it would still require duplication of lengthy unravelings.
Re: Elevator pitch - "assuming" [ In reply to ]
> On Tue, Jul 27, 2021 at 6:34 PM, Veesh Goldman <rabbiveesh@gmail.com> wrote:
>
> > I frequently find myself writing lines of code like the following
> >
> > $row->{nested}{key} = mutate_it($row->{nested}{key}) if $row->{nested}{key}

On Tue, Jul 27, 2021 at 11:44:23PM +0000, Mark Gardner wrote:
> $_ = mutate_it($_) for $row->{nested}{key}
>

Your replacement doesn't include the conditional.

Tony
Re: Elevator pitch - "assuming" [ In reply to ]
On Wed, Jul 28, 2021 at 1:48 AM Mark Gardner <mjg@phoenixtrap.com> wrote:

> Sorry, I see you wanted a conditional there too.
>
> $_ = mutate_it($_) for grep {$_} $row->{nested}{key}
>

I rather prefer …

$_ = mutate_it($_) for $row->{nested}{key} or ();

… which suggests the variant …

$_ = mutate_it($_) for $row->{nested}{key} // ();

Truth or definedness. Can't see a simple way to test for existence,
though … ?


Eirik
Re: Elevator pitch - "assuming" [ In reply to ]
You could even remove the extra braces if your condition is just an expression:

$_ = mutate_it($_) for grep $_, $row->{nested}{key}

On Tue, Jul 27, 2021 at 6:47 PM, Mark Gardner <mjg@phoenixtrap.com> wrote:

> Sorry, I see you wanted a conditional there too.
>
> $_ = mutate_it($_) for grep {$_} $row->{nested}{key}
>
> On Tue, Jul 27, 2021 at 6:44 PM, Mark Gardner <mjg@phoenixtrap.com> wrote:
>
>> $_ = mutate_it($_) for $row->{nested}{key}
>>
>> On Tue, Jul 27, 2021 at 6:34 PM, Veesh Goldman <rabbiveesh@gmail.com> wrote:
>>
>>> I frequently find myself writing lines of code like the following
>>>
>>> $row->{nested}{key} = mutate_it($row->{nested}{key}) if $row->{nested}{key}
>>>
>>> And I find it annoying that I have to keep repeating the name of the variable. The line processes a value if it's truthy, and leaving it falsy otherwise.
>>>
>>> it would be nice if we had a conditional statement that would also topicalize, so that it could be cut down to
>>> $_ = mutate_it($_) assuming $row->{nested}{key}
>>>
>>> Open questions that come to mind is what conditions other than truthiness would look like. Something like assuming $row->{nested}{key} : exists $_ perhaps?
>>>
>>> In terms of what the argument to assuming would be, I guess any lvalue would make sense.
>>>
>>> Existing options:
>>> There is a &&= operator, but it would still require duplication of lengthy unravelings.
Re: Elevator pitch - "assuming" [ In reply to ]
> On Jul 27, 2021, at 7:34 PM, Veesh Goldman <rabbiveesh@gmail.com> wrote:
>
> I frequently find myself writing lines of code like the following
>
> $row->{nested}{key} = mutate_it($row->{nested}{key}) if $row->{nested}{key}
>
> And I find it annoying that I have to keep repeating the name of the variable. The line processes a value if it's truthy, and leaving it falsy otherwise.
>
> it would be nice if we had a conditional statement that would also topicalize, so that it could be cut down to
> $_ = mutate_it($_) assuming $row->{nested}{key}

$_ && ($_ = mutate_it($_)) for $row->{nested}{key}

-FG
Re: Elevator pitch - "assuming" [ In reply to ]
On Wed, Jul 28, 2021 at 9:35 AM Veesh Goldman <rabbiveesh@gmail.com> wrote:

> I frequently find myself writing lines of code like the following
>
> $row->{nested}{key} = mutate_it($row->{nested}{key}) if $row->{nested}{key}
>
>
One thing I would look at doing is to rewrite mutate_it() so that it
actually mutates its argument in place, rather than returning a mutated
version of its argument.

Then the code becomes simply:
mutate_it($row->{nested}{key}) if $row->{nested}{key};

This then enables the solutions, as presented by others, to be written a
little more simply.

Cheers,
Rob
Re: Elevator pitch - "assuming" [ In reply to ]
In terms of the suggestions, I find there's more mental overhead when 1)
you're using `for` just as a topicalizer, which although it's documented
explicitly to be used as that purpose, is not the first thing you think
when looking at that code, and 2) the need to have another construct for
the conditional makes the code take longer to grok.

Theoretical `exists` syntax: $_ = mutate_it $_ assuming $row->{nested}{key}
is exists. (or maybe $row->{...} : exists). Don't think that's easily
expressible with the alternatives given above.

On Tue, Jul 27, 2021 at 9:16 PM sisyphus <sisyphus359@gmail.com> wrote:

>
>
> On Wed, Jul 28, 2021 at 9:35 AM Veesh Goldman <rabbiveesh@gmail.com>
> wrote:
>
>> I frequently find myself writing lines of code like the following
>>
>> $row->{nested}{key} = mutate_it($row->{nested}{key}) if
>> $row->{nested}{key}
>>
>>
> One thing I would look at doing is to rewrite mutate_it() so that it
> actually mutates its argument in place, rather than returning a mutated
> version of its argument.
>
> mutating in place is only an option sometimes. For example, Mojo's "trim"
is not in-place, and I use it in this sort of construction with trim all
the time. (not to reopen any canned worms on the topic of trim).

More comments:
On Tue, Jul 27, 2021 at 7:58 PM Felipe Gasper <felipe@felipegasper.com>
wrote:

> $_ && ($_ = mutate_it($_)) for $row->{nested}{key}


Better written as `$_ &&= mutate_it $_ for $row->{nested}{key}`, for the
record. (Not sure why there isn't a defined-and-assign operator. \\= to be
the opposite of //=?)
Re: Elevator pitch - "assuming" [ In reply to ]
Veesh Goldman writes:

> I frequently find myself writing lines of code like the following
>
> $row->{nested}{key} = mutate_it($row->{nested}{key}) if $row->{nested}{key}

So do I (for sufficiently vague definitions of “like”).

> it would be nice if we had a conditional statement that would also
> topicalize, so that it could be cut down to
>
> $_ = mutate_it($_) assuming $row->{nested}{key}

I'm not sure ‘assuming’ is the best name for it, but I don't have a
better one. From just seeing the subject of the mail, I didn't
immediately guess what assuming would do, but from the above line of
code I probably would.

But ‘assuming’ can mean something like ‘ignoring for the moment whether
or not this is true; just carry on as though it is’ — which is almost
the opposite of the desired meaning here.

‘provided’ is possible, though it would conflict with:
https://metacpan.org/pod/PerlX::Maybe#provided-$condition,-$x-=%3E-$y,-@rest


> Existing options: There is a &&= operator, but it would still require
> duplication of lengthy unravelings.

That's what I currently use, along the lines of:

$data{dispatched} &&= DateTime::OrSimilar->parse($data{dispatched);
$data{attachment} &&= path $data{attachment}; # From Path::Tiny

As well as repeating the topic, it also suffers from &&= truth rather
than definedness; an ‘and’ variant of the //= operator would be closer
to what I actually want there.

If we do introduce something like assuming, I think it makes more sense
to check for definedness: basically “Have we got a value here?”, which
should cover most cases.

On the other hand, I've stuck with using &&= like the above. I've never
tried to write a wrapper function or even search Cpan to see if there is
one.

Maybe we should see how far we can get with a Cpan module before trying
to get this into core Perl?

sisyphus writes:

> One thing I would look at doing is to rewrite mutate_it() so that it
> actually mutates its argument in place, rather than returning a
> mutated version of its argument.

In the examples above, the functions are constructors, inflating a
string into an object. Constructors normally take arguments and return
the new object; it would be an usual coding style to have them mutate
one of their arguments into the new object.

Smylers
Re: Elevator pitch - "assuming" [ In reply to ]
There is a potential difference. Grep and for create an alias
unconditionally, so must autovivivy the hash entry. A new keyword
``assuming'' would not have to do so.


I also must say that I find

   $_ = mutate_it($_) for grep $_, $row->{nested}{key}

much harder to read than

    $_ = mutate_it($_) assuming $row->{nested}{key}


Maybe we can reuse ``given'' for this purpose?

    $_ = mutate_it($_) given $row->{nested}{key}


HTH,

M4


Op 28-07-2021 om 01:57 schreef Mark Gardner:
> You could even remove the extra braces if your condition is just an
> expression:
>
> $_ = mutate_it($_) for grep $_, $row->{nested}{key}
>
> On Tue, Jul 27, 2021 at 6:47 PM, Mark Gardner <mjg@phoenixtrap.com
> <mailto:mjg@phoenixtrap.com>> wrote:
>> Sorry, I see you wanted a conditional there too.
>>
>> $_ = mutate_it($_) for grep {$_} $row->{nested}{key}
>>
>> On Tue, Jul 27, 2021 at 6:44 PM, Mark Gardner <mjg@phoenixtrap.com
>> <mailto:mjg@phoenixtrap.com>> wrote:
>>> $_ = mutate_it($_) for $row->{nested}{key}
>>>
>>>
>>> On Tue, Jul 27, 2021 at 6:34 PM, Veesh Goldman <rabbiveesh@gmail.com
>>> <mailto:rabbiveesh@gmail.com>> wrote:
>>>> I frequently find myself writing lines of code like the following
>>>>
>>>> $row->{nested}{key} = mutate_it($row->{nested}{key}) if
>>>> $row->{nested}{key}
>>>>
>>>> And I find it annoying that I have to keep repeating the name of
>>>> the variable. The line processes a value if it's truthy, and
>>>> leaving it falsy otherwise.
>>>>
>>>> it would be nice if we had a conditional statement that would also
>>>> topicalize, so that it could be cut down to
>>>> $_ = mutate_it($_) assuming $row->{nested}{key}
>>>>
>>>> Open questions that come to mind is what conditions other than
>>>> truthiness would look like. Something like assuming
>>>> $row->{nested}{key} : exists $_ perhaps?
>>>>
>>>> In terms of what the argument to assuming would be, I guess any
>>>> lvalue would make sense.
>>>>
>>>> Existing options:
>>>> There is a &&= operator, but it would still require duplication of
>>>> lengthy unravelings.
>>>
>>>
>>
>>
>
>
Re: Elevator pitch - "assuming" [ In reply to ]
On Wed, 28 Jul 2021 11:17:03 +0100
Smylers <Smylers@stripey.com> wrote:

> Maybe we should see how far we can get with a Cpan module before
> trying to get this into core Perl?

I don't believe it's currently possible as a keyword CPAN module;
keywords can't affect anything to their lefthand side.

Though actually it would be possible with my new infix operator
ability... if that got merged into Perl. :)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Elevator pitch - "assuming" [ In reply to ]
Paul "LeoNerd" Evans writes:

> On Wed, 28 Jul 2021 11:17:03 +0100
> Smylers <Smylers@stripey.com> wrote:
>
> > Maybe we should see how far we can get with a Cpan module before
> > trying to get this into core Perl?
>
> I don't believe it's currently possible as a keyword CPAN module;
> keywords can't affect anything to their lefthand side.

No, not entirely — hence “how far”.

But I think this would be possible, as a proof-of-concept:

assuming $value, sub { calculate_new_value_using $_ };

And if that gets traction or there's enough code which can be simplified
with it, that's evidence it would be useful in core Perl with nicer
syntax.

> Though actually it would be possible with my new infix operator
> ability... if that got merged into Perl. :)

I was interpreting it as being syntactically like foreach and if, in
that it would have a statement-postfix form, but could also precede a
block. Not because I've necessarily thought of lots of cases where a
block would be useful, but because it uses a familiar form, rather than
introducing an exception or a new class of syntax.

Smylers
Re: Elevator pitch - "assuming" [ In reply to ]
On Wed, 28 Jul 2021 12:34:27 +0100
Smylers <Smylers@stripey.com> wrote:

> I was interpreting it as being syntactically like foreach and if, in
> that it would have a statement-postfix form, but could also precede a
> block. Not because I've necessarily thought of lots of cases where a
> block would be useful, but because it uses a familiar form, rather
> than introducing an exception or a new class of syntax.

Oh well if you wanted it as a block with the keyword first, that's
easily possible as a keyword module:

assuming( $value ) {
$_ = calculate_new_value_using $_;
}

and in fact many languages already provide such syntax; called "with",
though it's often unconditional.

with( $value ) {
$_ = calculate_new_value_using $_;
}

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Elevator pitch - "assuming" [ In reply to ]
On Wed, Jul 28, 2021 at 1:53 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> and in fact many languages already provide such syntax; called "with",
> though it's often unconditional.
>
> with( $value ) {
> $_ = calculate_new_value_using $_;
> }
>

… and Perl provides it as "for", though unconditional, list-context-y,
and loop-y. But those are easily fixed …

for( $value // () ) {
$_ = calculate_new_value_using $_
}

(Is that really so far out?)


Eirik
Re: Elevator pitch - "assuming" [ In reply to ]
On Tue, Jul 27, 2021 at 6:35 PM Veesh Goldman <rabbiveesh@gmail.com> wrote:

> I frequently find myself writing lines of code like the following
>
> $row->{nested}{key} = mutate_it($row->{nested}{key}) if $row->{nested}{key}
>
> Existing options:
> There is a &&= operator, but it would still require duplication of lengthy
> unravelings.
>

Not in combination with other suggested tricks it doesn't:

$_ &&= mutate_it($_) for values %{$row->{nested}}; # mutate all truthy
values in the nested hash


--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash
Re: Elevator pitch - "assuming" [ In reply to ]
Op 29-07-2021 om 00:29 schreef Eirik Berg Hanssen:
> On Wed, Jul 28, 2021 at 1:53 PM Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk <mailto:leonerd@leonerd.org.uk>> wrote:
>
> and in fact many languages already provide such syntax; called "with",
> though it's often unconditional.
>
>   with( $value ) {
>     $_ = calculate_new_value_using $_;
>   }
>
>
>   … and Perl provides it as "for", though unconditional,
> list-context-y, and loop-y.  But those are easily fixed …
>
> for( $value // () ) {
>   $_ = calculate_new_value_using $_
> }
>

That actually doesn't work (try it). It doesn't modify $value.


That is IMHO the value of this proposal. It allows to work on a lvalue,
if it exists, not creating it if it doesn't It is a need I recognize,
and I wuld use this.


So as far as I can see, there are solutions that unconditionally
autovivivy $value (and are rather unreadable), solutions that do not
actually work, and the proposal that fills a real -- although maybe
debatable -- need. I'ld say we should have another look instead of
stating that it is already provided by existing constructs, AFAICS it isn't.


HTH,

M4
Re: Elevator pitch - "assuming" [ In reply to ]
On Thu, 29 Jul 2021 at 17:08, Martijn Lievaart <m@rtij.nl> wrote:

> Op 29-07-2021 om 00:29 schreef Eirik Berg Hanssen:
>
> On Wed, Jul 28, 2021 at 1:53 PM Paul "LeoNerd" Evans <
> leonerd@leonerd.org.uk> wrote:
>
>> and in fact many languages already provide such syntax; called "with",
>> though it's often unconditional.
>>
>> with( $value ) {
>> $_ = calculate_new_value_using $_;
>> }
>>
>
> … and Perl provides it as "for", though unconditional, list-context-y,
> and loop-y. But those are easily fixed …
>
> for( $value // () ) {
> $_ = calculate_new_value_using $_
> }
>
>
> That actually doesn't work (try it). It doesn't modify $value.
>
It does modify: `for` aliases each entry in the list (even `for my $x` is
an alias).

$ perl -le'sub calculate_new_value_using { shift() + 1 } my $value = 3;
for( $value // ()) { $_ = calculate_new_value_using $_; } print $value'
4
Re: Elevator pitch - "assuming" [ In reply to ]
Op 29-07-2021 om 12:45 schreef Tom Molesworth via perl5-porters:
>
>
> On Thu, 29 Jul 2021 at 17:08, Martijn Lievaart <m@rtij.nl
> <mailto:m@rtij.nl>> wrote:
>
> Op 29-07-2021 om 00:29 schreef Eirik Berg Hanssen:
>> On Wed, Jul 28, 2021 at 1:53 PM Paul "LeoNerd" Evans
>> <leonerd@leonerd.org.uk <mailto:leonerd@leonerd.org.uk>> wrote:
>>
>> and in fact many languages already provide such syntax;
>> called "with",
>> though it's often unconditional.
>>
>>   with( $value ) {
>>     $_ = calculate_new_value_using $_;
>>   }
>>
>>
>>   … and Perl provides it as "for", though unconditional,
>> list-context-y, and loop-y.  But those are easily fixed …
>>
>> for( $value // () ) {
>>   $_ = calculate_new_value_using $_
>> }
>>
>
> That actually doesn't work (try it). It doesn't modify $value.
>
> It does modify: `for` aliases each entry in the list (even `for my $x`
> is an alias).
>
> $ perl -le'sub calculate_new_value_using { shift() + 1 } my $value =
> 3; for( $value // ()) { $_ = calculate_new_value_using $_; } print $value'
> 4
>

Oops. My bad. Sorry.


M4
Re: Elevator pitch - "assuming" [ In reply to ]
On 2021-07-28 4:52 a.m., Paul "LeoNerd" Evans wrote:
> Oh well if you wanted it as a block with the keyword first, that's
> easily possible as a keyword module:
>
> assuming( $value ) {
> $_ = calculate_new_value_using $_;
> }
>
> and in fact many languages already provide such syntax; called "with",
> though it's often unconditional.
>
> with( $value ) {
> $_ = calculate_new_value_using $_;
> }

On 2021-07-28 3:17 a.m., Smylers wrote:
> I'm not sure ‘assuming’ is the best name for it, but I don't have a
> better one. From just seeing the subject of the mail, I didn't
> immediately guess what assuming would do, but from the above line of
> code I probably would.
>
> But ‘assuming’ can mean something like ‘ignoring for the moment whether
> or not this is true; just carry on as though it is’ — which is almost
> the opposite of the desired meaning here.

Putting aside the merit of the proposed feature itself...

I object to the use of the keyword "assuming" for it considering the wider
context that Raku uses that keyword for a much better and more generalized
feature, which is partial function application or priming.

https://docs.raku.org/routine/assuming

So if Perl gained a keyword "assuming" it should do the same thing as Raku's.

-- Darren Duncan
Re: Elevator pitch - "assuming" [ In reply to ]
On Wed, 28 Jul 2021 12:52:25 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> Oh well if you wanted it as a block with the keyword first, that's
> easily possible as a keyword module:
>
> assuming( $value ) {
> $_ = calculate_new_value_using $_;
> }

Veesh: As a way to progress this idea, perhaps you would consider this
plan?

If you make it as a keyword in that form, you don't immediately get the
infix notation but you would at least be able to experiment with the
idea in its block form as a regular CPAN module.

In addition it would probably be possible to do as an infix version as
well with my PL_infix_plugin branch, though that won't help "regular"
perl builds. :)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Elevator pitch - "assuming" [ In reply to ]
* Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2021-10-16 16:04:06 +0100]:

> On Wed, 28 Jul 2021 12:52:25 +0100
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
>
> > Oh well if you wanted it as a block with the keyword first, that's
> > easily possible as a keyword module:
> >
> > assuming( $value ) {
> > $_ = calculate_new_value_using $_;
> > }
>
> Veesh: As a way to progress this idea, perhaps you would consider this
> plan?
>
> If you make it as a keyword in that form, you don't immediately get the
> infix notation but you would at least be able to experiment with the
> idea in its block form as a regular CPAN module.
>
> In addition it would probably be possible to do as an infix version as
> well with my PL_infix_plugin branch, though that won't help "regular"
> perl builds. :)

This reminded me of the utility of a simple "case" construct. In fact, I've
often struggled with the attractiveness of using a hash-based dispatch for
composite values. But so far I have not been able to come up with a reasonable
scheme to get around the static nature of hash keys.

For example,

my $dispatch_hashref = {
key1 => \&do_key1,
key2 => \&do_key2,
#...
keyN => \&do_keyN,
};

if ( $dispatch_hashref->{$something} and q{CODE} eq ref $dispatch_hashref->{$something}) {
$dispatch_hashref->{$something}->();
}

This works great if C<$something> is a static string that can be used as a key in
C<$dispatch_hashref>. The benefit of this is the constant time look up, O(1).

But if I wanted to do something based on C<$something> being part of a derived value
or a range (e.g., C<$something > 0 and $something <= 10>), then I can't have such
a nice dispatch construct and checking has to be done either to compute a static string
based on membership in the TRUE set of any condition.

What I'd like to be able to do, as closely as possible to the original construct. Can an
"assume" construct help with this? I've looked at "Switch" on CPAN. I've not looked so
much into given/when, but I've never really liked that approach.

I tried to come up with an example of what I'd like to see, but was not able to come up
with anything.

Cheers,
Brett

>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: Elevator pitch - "assuming" [ In reply to ]
On Sat, 16 Oct 2021 23:40:03 +0000
Oodler 577 via perl5-porters <perl5-porters@perl.org> wrote:

> What I'd like to be able to do, as closely as possible to the
> original construct. Can an "assume" construct help with this? I've
> looked at "Switch" on CPAN. I've not looked so much into given/when,
> but I've never really liked that approach.

Have you looked at my Syntax::Keyword::Match?

https://metacpan.org/pod/Syntax::Keyword::Match

also this RT ticket describing a "range test" wishlist item:

https://rt.cpan.org/Ticket/Display.html?id=135134

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Elevator pitch - "assuming" [ In reply to ]
Hi Veesh,

It seemed like there was interest in this idea, but I’m not sure there’s enough justification for it.

You could analyse CPAN and try to identify situations where your assuming idea would be helpful. That would take quite a lot of effort, and I suspect might not produce the overwhelming support that would lead to a firm RFC.

Or you could try implementing it as a CPAN module, using one of the approaches suggested by Paul.

We discussed this in a recent PSC meeting and agreed that we’d like this idea to progress, but it needs you to carry it forward. If you’re not interested in doing that at the moment, we’ll record it as parked, for now.

What say ye?

Cheers,
Neil
Re: Elevator pitch - "assuming" [ In reply to ]
On Wed, 28 Jul 2021 at 01:48, Mark Gardner <mjg@phoenixtrap.com> wrote:

> Sorry, I see you wanted a conditional there too.
>
> $_ = mutate_it($_) for grep {$_} $row->{nested}{key}
>

IMO the best way to deal with this is to make the sub a mutator and have it
do the conditional logic, otherwise you fall prey to a subtle form of
autovivification like int he code above. The targets of a 'for' or 'map' or
'grep' loop are autovivified into existence, thus this code will create an
undefined 'key' in $row->{nested} if the key did not exist.

Some time back FC hacked in support so that autovivification is "smart" in
subroutines, so in modern perls you can write this:

sub mutate_it_maybe {
$_[0] &&= "foo";
}

mutate_it_maybe($row->{nested}{key});

and perl will not autovivifiy the "key" element into $row->{nested} unless
it is actually modified. Of course it would autovivify "nested" into $hash,
and $hash into a hash, were it needed, but it would not autovivify 'key'.
You can see this here:

perl -le'sub mutate_it_maybe { $_[0] &&= "foo"; } sub mutate_it {
$_[0]="bar"; } mutate_it($hash{should_autovivify});
mutate_it_maybe($hash{should_not_autovivify}); print for keys %hash;'

should print only "should_autovivify". In a much older perl it would also
print "should_not_autovivify".

So really the best way to do this is move it into your sub, or write a
wrapper like the one above.

If you want to avoid autovivification you need something like:

mutate_it_maybe($row,"nested","key");
sub mutate_it_maybe {
my $hash;
my $last= pop @_;
$hash= $hash->{$_} for @_;
$hash->{$last} &&= whatever($hash->{$last});
}

For what its worth I actually think this angle makes Veeshes proposal kinda
interesting. If we were to define "assuming" as a non-autovivicating list
operator/topicalizer similar to for/grep, then you could write your
original:

$_= mutate_it($_) assuming $row->{thing}{key};

and it would not autovivify, and it would not update false values. I could
actually see that being a useful addition, eg,

push @thing, $_ assuming @things;

would be like:

grep !!$_, @things;

but not autovivify the target like map/for/grep would. I could see myself
using that. I could also imagine it dieing in a bonfire of bikeshedding on
whether it would be truthiness, or definedness that is the underlying test.
:-)

Perhaps it would be better to have three forms: for_true, for_defined,
for_existing:

do_something($_) for_true $hash->{thing}, $hash->{other_thing};
do_something($_) for_defined $hash->{thing}, $hash->{other_thing};
do_something($_) for_existing $hash->{thing}, $hash->{other_thing};

Personally I definitely would NOT expect a "for_existing" operator to
autoviv. So I kinda like that concept. I actually think that would be quite
useful, this comes up a lot in for loops in my experience, eg when
refactoring code, or other things like that.

cheers,
ybes
Re: Elevator pitch - "assuming" [ In reply to ]
On Fri, Jul 30, 2021 at 8:57 PM Darren Duncan <darren@darrenduncan.net>
wrote:

> On 2021-07-28 4:52 a.m., Paul "LeoNerd" Evans wrote:
> > Oh well if you wanted it as a block with the keyword first, that's
> > easily possible as a keyword module:
> >
> > assuming( $value ) {
> > $_ = calculate_new_value_using $_;
> > }
> >
> > and in fact many languages already provide such syntax; called "with",
> > though it's often unconditional.
> >
> > with( $value ) {
> > $_ = calculate_new_value_using $_;
> > }
>


yeah, many languages already provide such syntax. Perl is one of them.

for( $value ) {
$_ = calculate_new_value_using $_;
}


--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash