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
