'some' and 'many' functions from the 'Alternative' type class

Question

What are the functions some and many in the Alternative type class useful for? Docs provide a recursive definition which I was unable to comprehend.

Answer 1

some and many can be defined as:

some f = (:) <$> f <*> many f
many f = some f <|> pure []

Perhaps it helps to see how some would be written with monadic do syntax:

some f = do
  x <- f
  xs <- many f
  return (x:xs)

So some f runs f once, then "many" times, and conses the results. many f runs f "some" times, or "alternatively" just returns the empty list. The idea is that they both run f as often as possible until it "fails", collecting the results in a list. The difference is that some f immediately fails if f fails, while many f will still succeed and "return" the empty list in such a case. But what all this exactly means depends on how <|> is defined.

Is it only useful for parsing? Let's see what it does for the instances in base: Maybe, [] and STM.

First Maybe. Nothing means failure, so some Nothing fails as well and evaluates to Nothing while many Nothing succeeds and evaluates to Just []. Both some (Just ()) and many (Just ()) never return, because Just () never fails! In a sense they evaluate to Just (repeat ()).

For lists, [] means failure, so some [] evaluates to [] (no answers) while many [] evaluates to [[]] (there's one answer and it is the empty list). Again some [()] and many [()] don't return. Expanding the instances, some [()] means fmap (():) (many [()]) and many [()] means some [()] ++ [[]], so you could say that many [()] is the same as tails (repeat ()).

For STM, failure means that the transaction has to be retried. So some retry will retry itself, while many retry will simply return the empty list. some f and many f will run f repeatedly until it retries. I'm not sure if this is useful thing, but I'm guessing it isn't.

So, for Maybe, [] and STM many and some don't seem to be that useful. It is only useful if the applicative has some kind of state that makes failure increasingly likely when running the same thing over and over. For parsers this is the input which is shrinking with every successful match.

Answer 2

E.g. for parsing (see the "Applicative parsing by example" section).