Why doesn't a prism set function return an Option/Maybe

I doubt there's one definitive answer, so I'll give you two here.

Origin

I believe prisms were first imagined (by Dan Doel, if my vague recollection is correct) as "co-lenses". Whereas a lens from s to a offers

get :: s -> a
set :: (s, a) -> s

a prism from s to a offers

coget :: a -> s
coset :: s -> Either s a

All the arrows are reversed, and the product, (,), is replaced by a coproduct, Either. So a prism in the category of types and functions is a lens in the dual category.

For simple prisms, that s -> Either s a seems a bit weird. Why would you want the original value back? But the lens package also offers type-changing optics. So we end up with

get :: s -> a
set :: (s, b) -> t

coget :: a -> s
coset :: t -> Either s b

Suddenly what we're getting back in the non-matching case may actually be a bit different! What's that about? Here's an example:

cogetLeft :: a -> Either a x
cogetLeft = Left

cosetLeft :: Either b x -> Either (Either a x) b
cosetLeft (Left b) = Right b
cosetLeft (Right x) = Left (Right x)

In the second (non-matching) case, the value we get back is the same, but its type has been changed.

Nice hierarchy

For both Van Laarhoven (as in lens) and profunctor style frameworks, both lenses and prisms can also stand in for traversals. To do that, they need to have similar forms, and this design accomplishes that. leftaroundabout's answer gives more detail on this aspect.

To answer the “why” – lenses etc. are pretty rigidly derived from category theory, so this is actually quite clear-cut – the behaviour you describe just drops out of the maths, it's not something anybody defined for any purpose but follows from far more general ideas.

Ok, that's not really satisfying.

Not sure if other languages' type systems are powerful enough to express this, but in principle and in Haskell, a prism is a special case of a traversal. A traversal is a way to “visit” all occurences of “elements” within some “container”. The classical example is

mapM :: Monad m => (a -> m b) -> [a] -> m [b]

This is typically used like

Prelude> mapM print [1..4]
1
2
3
4
[(),(),(),()]

The focus here is on: sequencing the actions/side-effects, and gathering back the result in a container with the same structure as the one we started with.

What's special about a prism is simply that the containers are restricted to contain either one or zero elements^† (whereas a general traversal can go over any number of elements). But the set operator doesn't know about that because it's strictly more general. The nice thing is that you can therefore use this on a lens, or a prism, or on mapM, and always get a sensible behaviour. But it's not the behaviour of “insert exactly once into the structure or else tell me if it failed”.

Not that this isn't a sensible operation, just it's not what lens libraries call “setting”. You can do it by explicitly matching and re-building:

set₁ :: Prism s a -> a -> s -> Maybe s
set₁ p x = case matching p x of
    Left _ -> Nothing
    Right a -> Just $ a ^. re p

^†_{More precisely: a prism seperates the cases: a container may either contain one element, and nothing else apart from that, or it may have no element but possibly something unrelated.}