Send Beginners mailing list submissions to
        beginners@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
        beginners-requ...@haskell.org

You can reach the person managing the list at
        beginners-ow...@haskell.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."


Today's Topics:

   1. Re:  Get rid of Maybes in complex types (Baa)
   2. Re:  Get rid of Maybes in complex types (Frerich Raabe)
   3. Re:  Get rid of Maybes in complex types (Imants Cekusins)
   4. Re:  Get rid of Maybes in complex types (Baa)


----------------------------------------------------------------------

Message: 1
Date: Thu, 6 Jul 2017 13:01:05 +0300
From: Baa <aqua...@gmail.com>
To: beginners@haskell.org
Subject: Re: [Haskell-beginners] Get rid of Maybes in complex types
Message-ID: <20170706130105.4112f723@Pavel>
Content-Type: text/plain; charset=US-ASCII

But will it work if I switch from one monad to another? Actually, I
have something like piping/conduit, and if I switch items in pipe from
`A Maybe` to `A Idenitity` - will it work? Whether it will be compiled?

Although I certainly can "map" items from one type to another...
Idea looks interesting sure :)


> Identity
> 
> http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Identity.html
> 
> may work:
> 
>  data A m = A {
>     a1 :: m B
>  }
>   data B m = B {
>     b1 :: m C
>     ... }
> 
> m: Maybe or Identity
> 
> - any good?
> 
> 
> 
> On 6 July 2017 at 11:12, Baa <aqua...@gmail.com> wrote:
> 
> > 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
> > _______________________________________________
> > Beginners mailing list
> > Beginners@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >  



------------------------------

Message: 2
Date: Thu, 06 Jul 2017 12:02:12 +0200
From: Frerich Raabe <ra...@froglogic.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Get rid of Maybes in complex types
Message-ID: <17d148352ca50aadd7821e4fd19ea...@froglogic.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 2017-07-06 10:12, Baa wrote:
> 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.

I understand that your data structures as sketched above are only needed for 
a short time, when reading/validating/fixing the input data - the rest of the 
program would either report an error (for unrecoverable problems) or process 
the validated data?

In that case, maybe you can avoid using Maybe in your data types for things 
which definitely must be present completely but rather returning a 'Maybe' 
value from your function which retrieves the data, i.e.:

   retrieveData :: ByteString -> Maybe A

Within 'retrieveData' you could then use different weakly-typed data 
structures which maybe only represent subsets of the data as you 
parse/validate/fix it. Not sure if/how that would work out, but maybe you 
could share some more concrete code (e.g. the actual logic for retrieving the 
data and the data types)?

-- 
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing


------------------------------

Message: 3
Date: Thu, 6 Jul 2017 13:40:35 +0300
From: Imants Cekusins <ima...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Get rid of Maybes in complex types
Message-ID:
        <CAP1qina6oheyFZwbchM5s0dLUiGtruT2UVSkKP3U9ScxK=t...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

how about a function (or a Monad Transformer) that checks values in one
place:

check::A Maybe -> Maybe (A Identity)

after values were checked, the after-checked functions will deal with A
Identity

the end result would be
   Maybe out



On 6 July 2017 at 13:01, Baa <aqua...@gmail.com> wrote:

> But will it work if I switch from one monad to another? Actually, I
> have something like piping/conduit, and if I switch items in pipe from
> `A Maybe` to `A Idenitity` - will it work? Whether it will be compiled?
>
> Although I certainly can "map" items from one type to another...
> Idea looks interesting sure :)
>
>
> > Identity
> >
> > http://hackage.haskell.org/package/mtl-2.2.1/docs/
> Control-Monad-Identity.html
> >
> > may work:
> >
> >  data A m = A {
> >     a1 :: m B
> >  }
> >   data B m = B {
> >     b1 :: m C
> >     ... }
> >
> > m: Maybe or Identity
> >
> > - any good?
> >
> >
> >
> > On 6 July 2017 at 11:12, Baa <aqua...@gmail.com> wrote:
> >
> > > 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
> > > _______________________________________________
> > > Beginners mailing list
> > > Beginners@haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> > >
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.haskell.org/pipermail/beginners/attachments/20170706/1e2042d6/attachment-0001.html>

------------------------------

Message: 4
Date: Thu, 6 Jul 2017 14:13:56 +0300
From: Baa <aqua...@gmail.com>
To: beginners@haskell.org
Subject: Re: [Haskell-beginners] Get rid of Maybes in complex types
Message-ID: <20170706141356.086afe40@Pavel>
Content-Type: text/plain; charset=US-ASCII

Imants, I'm not sure that I understood signatures.

Why 
  check::A Maybe -> Maybe (A Identity)

but not
  check::A Maybe -> A Identity

?

To filter (Nothing items must be throw out)? No more reasons for it?


> how about a function (or a Monad Transformer) that checks values in
> one place:
> 
> check::A Maybe -> Maybe (A Identity)
> 
> after values were checked, the after-checked functions will deal with
> A Identity
> 
> the end result would be
>    Maybe out
> 
> 
> 
> On 6 July 2017 at 13:01, Baa <aqua...@gmail.com> wrote:
> 
> > But will it work if I switch from one monad to another? Actually, I
> > have something like piping/conduit, and if I switch items in pipe
> > from `A Maybe` to `A Idenitity` - will it work? Whether it will be
> > compiled?
> >
> > Although I certainly can "map" items from one type to another...
> > Idea looks interesting sure :)
> >
> >  
> > > Identity
> > >
> > > http://hackage.haskell.org/package/mtl-2.2.1/docs/  
> > Control-Monad-Identity.html  
> > >
> > > may work:
> > >
> > >  data A m = A {
> > >     a1 :: m B
> > >  }
> > >   data B m = B {
> > >     b1 :: m C
> > >     ... }
> > >
> > > m: Maybe or Identity
> > >
> > > - any good?
> > >
> > >
> > >
> > > On 6 July 2017 at 11:12, Baa <aqua...@gmail.com> wrote:
> > >  
> > > > 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
> > > > _______________________________________________
> > > > Beginners mailing list
> > > > Beginners@haskell.org
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> > > >  
> >
> > _______________________________________________
> > Beginners mailing list
> > Beginners@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >  



------------------------------

Subject: Digest Footer

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


------------------------------

End of Beginners Digest, Vol 109, Issue 6
*****************************************

Reply via email to