Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/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: How to design functions so they can be part of other
larger systems? (Darren Grant)
2. Re: hiding members of a data, separate accessors instead
(Emmanuel Touzery)
3. Re: hiding members of a data, separate accessors instead
(Gabriel Gonzalez)
----------------------------------------------------------------------
Message: 1
Date: Sun, 24 Mar 2013 12:15:26 -0700
From: Darren Grant <therealklu...@gmail.com>
Subject: Re: [Haskell-beginners] How to design functions so they can
be part of other larger systems?
To: Haskell Beginners <beginners@haskell.org>
Message-ID:
<CA+jD6SjjYdxc-WDbg4RZY7-ikRKxjAkjqvXGY=mefe7us7u...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
This is a great bridge article, thanks!
On 2013-03-24 10:45 AM, "Gabriel Gonzalez" <gabriel...@gmail.com> wrote:
> On 03/24/2013 10:30 AM, Costello, Roger L. wrote:
>
>> Hi Folks,
>>
>> I read this statement by Tim Berners-Lee [1]:
>>
>> It is not only necessary to make sure your own system
>> is designed to be made of modular parts. It is also
>> necessary to realize that your own system, no matter
>> how big and wonderful it seems now, should always be
>> designed to be a part of another larger system.
>>
>> Recently I have been working hard to learn how to better modularize. But
>> now TBL says that I must do more - I must not only modularize well, but I
>> must also build the modules so that they can be part of other larger
>> systems.
>>
>> How do I design modules so that they may be part of other larger systems?
>> Are there any articles that give guidelines on how to do this? What are
>> your thoughts on how to do this?
>>
>>
>>
>
> I recommend that you read the following post I wrote:
>
> http://www.haskellforall.com/**2012/08/the-category-design-**pattern.html<http://www.haskellforall.com/2012/08/the-category-design-pattern.html>
>
> It introduces category theory in the context of designing modular and
> resuable components. Category theory differentiates itself from other
> vague notions of modularity by providing an elegant and precise definition
> of what it means for something to be "modular".
>
> /Roger
>>
>> [1]
>> http://www.w3.org/**DesignIssues/Principles.html<http://www.w3.org/DesignIssues/Principles.html>
>>
>> ______________________________**_________________
>> Beginners mailing list
>> Beginners@haskell.org
>> http://www.haskell.org/**mailman/listinfo/beginners<http://www.haskell.org/mailman/listinfo/beginners>
>>
>>
>
>
> ______________________________**_________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/**mailman/listinfo/beginners<http://www.haskell.org/mailman/listinfo/beginners>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130324/e5531382/attachment-0001.htm>
------------------------------
Message: 2
Date: Sun, 24 Mar 2013 20:24:55 +0100
From: Emmanuel Touzery <etouz...@gmail.com>
Subject: Re: [Haskell-beginners] hiding members of a data, separate
accessors instead
To: "beginners@haskell.org" <beginners@haskell.org>
Message-ID:
<CAC42Re=+smehuasjsyplrzxa5oqlu7ukptpr0_rirxnadyb...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
But then since the library is using (..) that would mean everything is
exported?
For instance testing on the Request data:
http://hackage.haskell.org/packages/archive/http-streams/0.4.0.0/doc/html/src/Network-Http-Types.html#Request
module Network.Http.Types ( Request(..),
data Request = Request { qMethod :: !Method, qHost
:: Maybe ByteString, qPath :: !ByteString, qBody
:: !EntityBody, qExpect :: !ExpectMode, qHeaders ::
!Headers }
----
{-# LANGUAGE OverloadedStrings #-}
import Network.Http.Client
main = do
q <- buildRequest $ do
http GET "/"
setAccept "text/html"
print q
print $ qMethod q
---
test-hs.hs:11:17: Not in scope: `qMethod'
With regards to what Daniel wrote, I realize my email was confusing. When I
was talking about warnings I was talking of another problem entirely, that
i probably should not have mentioned in this context.
In that other context I had data declarations for types that I would
instanciate only from Data.Aeson parsing from JSON. I would then only use
pattern matching on the instances, never call the "accessor functions" by
themselves, then I get a warning that they're unused which annoys me. But
it's quite unrelated to this mail...
Emmanuel
On Sun, Mar 24, 2013 at 6:34 PM, Gabriel Gonzalez <gabriel...@gmail.com>wrote:
> **
> Assume you have the following type:
>
> data Type = T { field1 :: String, field2 :: Double }
>
> ... and you want to export the type `Type` and the acessors `field1` and
> `field2`, but not the constructor `T`, then you would write:
>
> module MyModule (
> Type(field1, field2)
> ) where
>
> Another way to do this is like so:
>
> module MyModule (
> Type,
> field1,
> field2
> ) where
>
> That's perfectly legal, too.
>
> Normally, when you write something like:
>
> module MyModule (
> Type(..)
> ) where
>
> the ".." expands out to:
>
> module MyModule (
> Type(T, field1, field2)
> ) where
>
> All the first solution does is just leave out the T constructor from those
> exports.
>
>
> On 03/24/2013 09:14 AM, Emmanuel Touzery wrote:
>
> hi,
>
> i was looking at the response type in http-streams:
>
> http://hackage.haskell.org/packages/archive/http-streams/0.4.0.0/doc/html/Network-Http-Client.html#t:Response
>
> I'm used that simply the data type and all its "members" are visible --
> the functions to access its contents. But in this case on the HTML
> documentation the response type looks like it has no members. And the
> author has defined like "public accessors" later in the code:
>
> getStatusCode :: Response -> StatusCode
> getStatusCode = pStatusCode
>
> So I'm not even sure how he achieved that the members are not visible,
> the data are exported with (..) as is usually done... And the other thing
> is why
> would you do that.. You could name the member getStatusCode in the first
> place, but then it might increase encapsulation to hide it (depending on
> how he
> managed to hide the members).. But did you then make
> it impossible to deconstruct a Response through pattern matching? That
> sounds like a minus... Although pattern matching on a data with 6 fields
> is always going to be a pain and decreasing the chances for modifying
> the data type without breaking compatibility.
>
> These "members" are also causing me problems in other situations, for
> instance I have some cases when I use a data type only a few times and with
> -Wall the compiler tells me I don't use the accessor; in fact I read that
> value from the data, but through pattern matching/deconstruction only, not
> through that particular function. I'm thinking to try to hide the warning
> as I think my code is correct.
>
> Anyway I'm curious on the mechanism used by that library... I've already
> noticed a few nice tricks in this library, like a small state monad to take
> optional parameters, much more elegant than any other mechanism i've seen
> so far to achieve the same effect.
>
> Thank you!
>
> Emmanuel
>
>
> _______________________________________________
> Beginners mailing
> listBeginners@haskell.orghttp://www.haskell.org/mailman/listinfo/beginners
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130324/52bb56a6/attachment-0001.htm>
------------------------------
Message: 3
Date: Sun, 24 Mar 2013 13:00:26 -0700
From: Gabriel Gonzalez <gabriel...@gmail.com>
Subject: Re: [Haskell-beginners] hiding members of a data, separate
accessors instead
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Message-ID: <514f5b5a.1040...@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/24/2013 12:24 PM, Emmanuel Touzery wrote:
> But then since the library is using (..) that would mean everything is
> exported?
>
It only means that those fields are exported from that specific module.
Downstream modules that use Network.Http.Types internally may or may not
re-export everything.
Your example below doesn't import Network.Http.Types; it imports
Network.Http.Client. If you look at the source for Network.Http.Client
you will see that it does not re-export everything it imported from
Network.Http.Types:
http://hackage.haskell.org/packages/archive/http-streams/0.4.0.0/doc/html/src/Network-Http-Client.html
When you import Network.Http.Client, `ghc` only uses whatever is in the
export list of Network.Http.Client.
> For instance testing on the Request data:
>
> http://hackage.haskell.org/packages/archive/http-streams/0.4.0.0/doc/html/src/Network-Http-Types.html#Request
> module Network.Http.Types (
> Request(..),
> data Request
> = Request {
> qMethod :: !Method,
> qHost :: Maybe ByteString,
> qPath :: !ByteString,
> qBody :: !EntityBody,
> qExpect :: !ExpectMode,
> qHeaders :: !Headers
> }
>
> ----
> {-# LANGUAGE OverloadedStrings #-}
>
> import Network.Http.Client
>
> main = do
> q <- buildRequest $ do
> http GET "/"
> setAccept "text/html"
>
> print q
> print $ qMethod q
>
> ---
>
> test-hs.hs:11:17: Not in scope: `qMethod'
>
> With regards to what Daniel wrote, I realize my email was confusing.
> When I was talking about warnings I was talking of another problem
> entirely, that i probably should not have mentioned in this context.
> In that other context I had data declarations for types that I would
> instanciate only from Data.Aeson parsing from JSON. I would then only
> use pattern matching on the instances, never call the "accessor
> functions" by themselves, then I get a warning that they're unused
> which annoys me. But it's quite unrelated to this mail...
>
> Emmanuel
>
>
>
> On Sun, Mar 24, 2013 at 6:34 PM, Gabriel Gonzalez
> <gabriel...@gmail.com <mailto:gabriel...@gmail.com>> wrote:
>
> Assume you have the following type:
>
> data Type = T { field1 :: String, field2 :: Double }
>
> ... and you want to export the type `Type` and the acessors
> `field1` and `field2`, but not the constructor `T`, then you would
> write:
>
> module MyModule (
> Type(field1, field2)
> ) where
>
> Another way to do this is like so:
>
> module MyModule (
> Type,
> field1,
> field2
> ) where
>
> That's perfectly legal, too.
>
> Normally, when you write something like:
>
> module MyModule (
> Type(..)
> ) where
>
> the ".." expands out to:
>
> module MyModule (
> Type(T, field1, field2)
> ) where
>
> All the first solution does is just leave out the T constructor
> from those exports.
>
>
> On 03/24/2013 09:14 AM, Emmanuel Touzery wrote:
>> hi,
>>
>> i was looking at the response type in http-streams:
>>
>> http://hackage.haskell.org/packages/archive/http-streams/0.4.0.0/doc/html/Network-Http-Client.html#t:Response
>>
>> I'm used that simply the data type and all its "members" are
>> visible --
>> the functions to access its contents. But in this case on the HTML
>> documentation the response type looks like it has no members. And the
>> author has defined like "public accessors" later in the code:
>>
>> getStatusCode :: Response -> StatusCode
>> getStatusCode = pStatusCode
>>
>> So I'm not even sure how he achieved that the members are not
>> visible,
>> the data are exported with (..) as is usually done... And the
>> other thing is why
>> would you do that.. You could name the member getStatusCode in
>> the first
>> place, but then it might increase encapsulation to hide it
>> (depending on how he
>> managed to hide the members).. But did you then make
>> it impossible to deconstruct a Response through pattern matching?
>> That
>> sounds like a minus... Although pattern matching on a data with 6
>> fields
>> is always going to be a pain and decreasing the chances for modifying
>> the data type without breaking compatibility.
>>
>> These "members" are also causing me problems in other situations,
>> for instance I have some cases when I use a data type only a few
>> times and with -Wall the compiler tells me I don't use the
>> accessor; in fact I read that value from the data, but through
>> pattern matching/deconstruction only, not through that particular
>> function. I'm thinking to try to hide the warning as I think my
>> code is correct.
>>
>> Anyway I'm curious on the mechanism used by that library... I've
>> already noticed a few nice tricks in this library, like a small
>> state monad to take optional parameters, much more elegant than
>> any other mechanism i've seen so far to achieve the same effect.
>>
>> Thank you!
>>
>> Emmanuel
>>
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org <mailto:Beginners@haskell.org>
>> http://www.haskell.org/mailman/listinfo/beginners
>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130324/7810bb0a/attachment.htm>
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 57, Issue 35
*****************************************
