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: Haskell and design patterns (Alex Rozenshteyn)
2. Re: why is there no typeclass common to all containers?
(Peter Hall)
----------------------------------------------------------------------
Message: 1
Date: Thu, 02 Jun 2016 16:01:53 +0000
From: Alex Rozenshteyn <rpglove...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Haskell and design patterns
Message-ID:
<CALm==bvt7hejtdgc1s-o-0waqw_bad1ncjpaqy6rlfvf6-7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sounds reasonable. A few comments:
Avoid the temptation to think of monads as "containers" as much as
possible, some containers aren't monads (Set, for example) and many monads
aren't containers (IO, Reader, Writer, State, etc.).
As I understand "design pattern"s, they are approaches to solving problems
that cannot be completely abstracted away. In that sense, "monad"s are no
stranger a design pattern than "visitor".
Some resources (many of which could be found by searching for "haskell
design patterns", but which I personally found interesting):
Design patterns for functional strategic programming
<https://scholar.google.com/scholar?cluster=4442103092796807160&hl=en&as_sdt=0,21>
(discusses
patterns which are found in functional programming)
http://blog.ezyang.com/2010/05/design-patterns-in-haskel/ (relates the
original GoF patterns to Haskell alternatives)
http://www.haskellforall.com/2012/08/the-category-design-pattern.html
http://www.haskellforall.com/2012/09/the-functor-design-pattern.html
(more design principles than design patterns, IMO, but good, clear reads)
http://dev.stephendiehl.com/hask/ (an all around amazing resource of
curated material)
On Thu, Jun 2, 2016 at 1:30 AM Dennis Raddle <dennis.rad...@gmail.com>
wrote:
> I have been using Haskell on and off, as a hobbyist, for five years. I
> haven't been diligent in training myself on it, so I am learning slowly. It
> was confusing at first, coming from an imperative background.
>
> It occurred to me the other day that Haskell typeclasses are a kind of
> "design pattern." They identify a common pattern and provide a solution.
> I've been reading about design patterns in C++ for years. Haskell patterns
> are a twist on that.
>
> The imperative view looks at a task in a certain way, often conceiving of
> it as steps that mimic how human thoughts would go, and finding big general
> patterns that occur in different big applications.
>
> I don't want to speak for all of Haskell, but at least some Haskell
> patterns are smaller-scale and more attuned to the language of programming
> rather than the language of human thought.
>
> For instance, the Monad. The common use case is this---you have some
> "things," and you have a "container" that can accept more than one type of
> "thing." The common patterns are
>
> - you need to wrap things in the container
> - you need to unwrap things
> - you need to modify things while in their container
> - you have functions that operate on containers
> - you have functions that operate on the things, but maybe you don't want
> to unwrap them first. or maybe you do.
>
> To an imperative programmer, this is bizarre. What things are you talking
> about? What containers? You have not defined either one, so why can you say
> anything specific? Why all this emphasis on wrapping and unwrapping?
>
> Yet this is a design pattern all the same. It gets weird when you realize
> that the Maybe monad, conceived in human-thought terms, has totally
> different behavior than the list monad. Yet they are the same design
> pattern and have a relationship that is more concisely expressed
> mathematically than in human thought.
>
> The abundance of operators for wrapping/unwrapping/operating seems, if I
> understand right, closely related to the conciseness of Haskell. If you can
> use your containers without unwrapping them first, then by all means you
> don't want extra syntax just to do so. Same if you have functions that only
> operate on unwrapped things.
>
> Haskell patterns are "lightweight" also helping with the conciseness. The
> closest thing to a "container" in C++ is a class, which is a dozen times
> heavier than a Functor, Applicative, or Monad. Actually you really need a
> "template class" which is like a tank compared to Functor which is a skinny
> guy fighting with a short knife (who can usually get the job done just
> fine, thank you).
>
> Any comments welcome. I'm just trying to get a good perspective on Haskell.
>
> Mike
>
> _______________________________________________
> 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/20160602/4497e87e/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 3 Jun 2016 11:40:06 +0100
From: Peter Hall <peterj...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] why is there no typeclass common to
all containers?
Message-ID:
<caa6hak79optaozsyoqejeuol6u9rhfztoqtmpncxzf8o_2d...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
> As for why Haskell doesn't allow natural overloading of any function name
merely by choosing another name, does anyone know?
Haskell requires that overloaded functions are part of a typeclass. This
isn't a big requirement - you can easily make any type into an instance of
a new typeclass.
The reason why this is important is that it ensures that the meaning and
intent of the function are the same, not just a coincidental naming
collision.
Peter
On 1 June 2016 at 18:18, Silent Leaf <silent.le...@gmail.com> wrote:
> map and set are not what? I didn't get it.
>
> That's cool, I'll look into it!
> As for why Haskell doesn't allow natural overloading of any function name
> merely by choosing another name, does anyone know?
>
>
> Le mercredi 1 juin 2016, Alex Rozenshteyn <rpglove...@gmail.com> a ?crit :
> > Map is (you map over the values, not the keys).
> >
> > On Wed, Jun 1, 2016 at 1:14 AM Tony Morris <tonymor...@gmail.com> wrote:
> >>
> >> Map and Set are not.
> >>
> >> On 01/06/2016 8:57 AM, "Jeffrey Brown" <jeffbrown....@gmail.com> wrote:
> >>>
> >>> In Haskell typeclasses are based on what you want to do with
> something. If, for instance, you want to be able to map over a container,
> you can make it an instance of class Functor -- which all the standard
> containers (List, Map, Set, Tree, Maybe ...) already are.
> >>> On Tue, May 31, 2016 at 3:26 PM, Silent Leaf <silent.le...@gmail.com>
> wrote:
> >>>>
> >>>> In fact it all comes down to trying to add partially a feature absent
> from the Haskell language, which is the ability to distinguish values both
> on name *and* on type --thus allowing two variables of the same name if
> they have different types.
> >>>> Honestly i don't see the drawback of that name system, but i guess
> there must be one otherwise it'd have been chosen by default instead of the
> typeblind current name system.
> >>>>
> >>>> Le mercredi 1 juin 2016, Silent Leaf <silent.le...@gmail.com> a
> ?crit :
> >>>> > All in the title. I haven't used them much, but I saw Map or Vector
> types were forcing the user to use qualified functions unless you want
> nameclash with the more basic, typically list-oriented functions.
> >>>> > So, why not have a massive, general purpose interface so the type
> only can separate between containers --which would allow for
> cross-container polymorphism, i suppose, more easily, even though it's not
> necessarily the most widespread need.
> >>>> > So, do i miss something? Is there in fact a class of that kind? If
> so why not?
> >>>> > Thanks in advance! :)
> >>>> _______________________________________________
> >>>> Beginners mailing list
> >>>> Beginners@haskell.org
> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jeffrey Benjamin Brown
> >>> _______________________________________________
> >>> 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
> >
>
> _______________________________________________
> 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/20160603/98350733/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 96, Issue 5
****************************************
