Hello Dear List! Consider, I retrieve from external source some data. Internally it's represented as some complex type with `Maybe` fields, even more, some of fields are record types and have `Maybe` fields too. They are Maybe's because some information in this data can be missing (user error or it not very valuable and can be skipped): data A = A { a1 :: Maybe B ... } data B = B { b1 :: Maybe C ... } I retrieve it from network, files, i.e. external world, then I validate it, report errors of some missing fields, fix another one (which can be fixed, for example, replace Nothing with `Just default_value` or even I can fix `Just wrong` to `Just right`, etc, etc). After all of this, I know that I have "clean" data, so all my complex types now have `Just right_value` fields. But I need to process them as optional, with possible Nothing case! To avoid it I must create copies of `A`, `B`, etc, where `a1`, `b1` will be `B`, `C`, not `Maybe B`, `Maybe C`. Sure, it's not a case. After processing and filtering, I create, for example, some resulting objects: data Result { a :: A -- not Maybe! ... } And even more: `a::A` in `Result` (I know it, after filtering) will not contain Nothings, only `Just right_values`s. But each function which consumes `A` must do something with possible Nothing values even after filtering and fixing of `A`s. I have, for example, function: createResults :: [A] -> [Result] createResults alst = ... case of (a1 theA) -> Just right_value -> ... Nothing -> logError undefined -- can not happen Fun here is: that it happens (I found bug in my filtering code with this `undefined`). But now I thought about it: what is the idiomatic way to solve such situation? When you need to have: - COMPLEX type WITH Maybes - the same type WITHOUT Maybes Alternative is to keep this Maybes to the very end of processing, what I don't like. Or to have types copies, which is more terrible, sure. PS. I threw IOs away to show only the crux of the problem. --- Cheers, Paul