[Solved] Using `whenJust`

Learn
1

Stack’s code makes a lot of use of base's when :: Applicative f => Bool -> f () -> f (). I wondered if there was a Applicative f => Maybe a -> (a -> f()) -> f () and Hoogle found whenJust from extra (already a dependency of Stack). So:

case mSomething of
  Nothing -> pure ()
  Just value -> do
    complicatedActionWith value

can become:

whenJust mSomething $ \value -> do
  complicatedActionWith value

Which, for me, is a more expressive syntax. My question is: Is there any downside with replacing the former form with the latter form? The former form appears a lot in Stack’s code.

EDIT: I suppose what I am really asking is: Can I safely assume that the compiler does not care, one way or the other?

2 Likes
2

I wondered if there was a Applicative f => Maybe a -> (a -> f()) -> f ()

The answer is always traverse.

Well, flip traverse_ = for_ in this case.

10 Likes
3

The Haddock documentation for whenJust does say it is a specialised for_.

2 Likes
4

hah the other day I wanted a function :: Monoid a => Maybe a -> a; fromMaybe mempty

my work’s internal hoogle’s first result?

fold :laughing: love it

5
...or: 
do value <- whenJust mSomething pure
   complicatedActionWith value

As @tdammers noted here, it will depend on what the previous programmers (and now yourself) consider to be important: in some places using the case-expression could be more informative; in other places: not so much. But I would tend to leave alone those places where detailed “walk-though” documentation exists - the writer of that documentation (and possibly the associated code) would have chosen that more verbose style for a reason…

2 Likes
6

If by “the compiler does not care” you mean that it is able to optimise the latter to the former, then yes, the compiler does not care

1 Like
7

I still would prefer whenJust over for_ here. It’s just more readable, it gives you more context. The same way I prefer map over fmap when I know I’m working with lists.

7 Likes
8

For for_ (and other Foldable-related functions like length) I tend to use for_ @Maybe instead of whenJust. That gives a bit of context without having to remember the name of the specialized function.

5 Likes
9

Me too. I have so many traverse_/fold/foldMaps written by a previous author on my current codebase at work, and it’s always very headscratching to understand what they mean.

5 Likes
10

I feel like much crisis could be averted by having HLS inline the definition for you (and then you undo it).

Not an option for code review, though.

11

The Agda code base also uses whenJust (rather than for_), to improve readability.
We use whenJust a lot!

3 Likes
12

I’m confused by this example. Wouldn’t value <- whenJust mSomething pure always return unit? value cant have a value if mSomething is Nothing

13

Hmm:

whenJust mg k = maybe (pure ()) k mg

              = case mg of Just x  -> k x
                           Nothing -> pure ()

…now to look at when:

when p s  = if p then s else pure ()
 -- or --
          = if p then k () else pure ()  {- if s = k () -}

Since in this case the continuation isn’t always used - yes, you’re correct; my “redundant continuation” heuristic doesn’t actually apply (for a change!).

14

You could write something like what you wrote if you sprinkle in the MaybeT transformer and an appropriate “handler”:

whenMaybeT :: Alternative f => MaybeT f () -> f ()
whenMaybeT (MaybeT m) = m >>= maybe empty pure

...

  whenMaybeT $ do value <- hoistMaybe mSomething
                  lift (complicatedActionWith value)

I guess Lean 4’s new do notation sugar could support something like that more elegantly.

15

No need for do notation sugar. One test of a good effect system is whether it supports this use case cleanly. Here’s what it looks like in my, unreleased, effect system, Bluefin:

withJump $ \j -> do
    value <- unwrapOrJumpTo j mSomething
    complicatedActionWith value
2 Likes
16

Many thanks for the advice. I decided to make (and have now made) greater use of whenJust in Stack’s code.

1 Like