add Array.foldlM' and foldlWithKeyM'

[ocramz]

No description provided.

[ocramz]

Hi ! I was missing a monadic indexed fold, I hope you like this addition :)

[ocramz]

ping!

[treeowl]

Sorry, I seem to have missed this. I have some concerns.

If we add a left fold, we will certainly also want to add a right fold, since HashMap doesn't care. I'll assume this change.

If we add these to HashMap, we surely want to add similar ones to HashSet. I'll assume this change as well.

Why a strict fold? In strict monads (the only ones for which this strictness is really meaningful anyway), the user can insert strictness into a lazy fold by supplying a function that's strict in the accumulator. I'm not saying we necessarily shouldn't offer the strict version (there are likely efficiency benefits for certain monads), but offering only that, and not the more fundamental lazy version, seems odd.

Do we get a real performance benefit by implementing this directly rather than using foldrWithKey? If so, that would be a strong reason to add this. If not, I'd really want to see a formal proposal on the libraries list to get community guidance. My bet is that the versions below are just fine.

foldlWithKeyM :: Monad m => (a -> k -> v -> m a) -> a -> HashMap k v -> m a
foldlWithKeyM f a0 hm = foldrWithKey go pure hm a0
  where
    go k v r a = f a k v >>= r
{-# INLINE foldlWithKeyM #-}

foldlWithKeyM' :: Monad m => (a -> k -> v -> m a) -> a -> HashMap k v -> m a
foldlWithKeyM' f a0 hm = foldrWithKey go (pure $!) hm a0
  where
    go k v r !a = f a k v >>= r
{-# INLINE foldlWithKeyM' #-}

[ocramz]

Thank you @treeowl for your feedback! I hadn't thought of performance implications to be honest and I'll apply the changes you propose:

• revert to the non-strict implementations based on foldrWithKey you propose
• add foldrWithKeyM in HashMap
• add foldrWithKeyM, foldlWithKeyM, foldlWithKeyM' in HashSet

[treeowl]

Oh, silly me... We don't need those lazy versions in HashSet because they're in Data.Foldable. But I'd really like to see a proposal sent to [email protected] to determine which of these the community thinks are worth adding.

[sjakobi]

Marking as a draft, since this PR doesn't seem to be ready for review.

[ocramz]

@sjakobi @treeowl I don't have the bandwidth to push this forward for the time being.

[sjakobi]

Thanks for the update, @ocramz!

For future reference, here's a related feature request for containers: haskell/containers#678

Since it's an API extension without an obvious precedent, I agree that it should be discussed on the libraries list.