List should have `.do` method as Supply

[FCO]

Supply has the .do method that should be used only for its side-effects, it works kind of as a map that always return $_. But lists do not have that method. That would make sense to exist that method on lists.

[FCO]

https://colabti.org/irclogger/irclogger_log/raku?date=2019-10-21#l103

[jnthn]

I presume on all Iterables rather than simply on list?

How would we choose to define it on items?

[FCO]

Yes, Iterables...

Sorry, what do you mean with “choose to define it on items”?

_{Sent with GitHawk}

[jnthn]

Does 42.do(*.say) evaluate to 42 or (42,).Seq?

[FCO]

I think 42 would be more useful... but I’m not sure...

_{Sent with GitHawk}

[FCO]

It would behave as a given that returns the unchanged value...

_{Sent with GitHawk}

[FCO]

Writing Red I found an example that could be using .do on scalar:

method begin {
    my $trans = self.new-connection;
    $trans.prepare(Red::AST::BeginTransaction.new).map: *.execute;
    $trans
}

could be just

method begin {
    self.new-connection.do: {
        .prepare(Red::AST::BeginTransaction.new).map: *.execute;
    }
}

[ab5tract]

I was just thinking about this, though I had envisioned it a bit differently.

Basically I wonder if this would fit @FCO 's vision:

# this is actually broken, what 
# we actually want is to ensure 
# that the signature to &block 
# put is raw on its param.
# that way we only affect 
# mutations, whereas this stores 
# the output of side effects as 
# well

method do(&block) { 
   for self.list -> $_ is raw    
      { $_ = &block($_) } 
   }
}

Basically providing a method version of a for where the idea is strictly related to side effects and/or mutation of elements.

I would actually have gone with 'each' for this, but it seems that Supply.do is already a thing. Also, 'do' fits the Scalar case better, a use case I find quite compelling.

But maybe I'm misunderstanding @FCO's intent here.