[Haskell-beginners] a problem with maps

[Julian Porter]

Well, speaking of rigour, I don't think applicative functors, etc are actually the right approach.  Using the list monad gives a much clearer idea of what's going on, plus it's massively generalisable.  

See http://jpembeddedsolutions.wordpress.com/2011/07/24/combining-haskell-lists-with-monads/ for a description.

Julian Porter
julian.porter at porternet.org
http://www.porternet.org


On 24 Jul 2011, at 01:13, aditya siram wrote:

> Ertugul,
> I admire your passion for rigor and discipline. It is not natural for
> me but I am slowly coming to the same place.
> 
> I also feel that Haskell development is like learning to play music.
> I've seen many a student (myself included) turn away from an
> instrument because of an over-emphasis on scales, arpeggios etc. and
> less on playing what sounds good. It is true that eventually to play
> seriously some understanding of that theory is required but the
> musician will come to that conclusion on their own.
> 
> They will hear a pattern over and over and wonder if it has a name -
> then you show them the major scale and it will all make sense because
> it will be a solution to a problem, not a solution waiting for a
> problem.
> 
> In some ways I feel that the Haskell community because of their
> expertise and enthusiasm gives users answers to questions they haven't
> asked yet. When they do (inevitably) ask your awesome monad tutorial
> (which helped me a great deal) will be there.
> 
> -deech
> 
> On Sat, Jul 23, 2011 at 6:39 PM, Ertugrul Soeylemez <es at ertes.de> wrote:
>> David Place <d at vidplace.com> wrote:
>> 
>>>> Point taken, but to get serious with Haskell you will want to learn
>>>> applicative functors and at least the function arrow anyway.
>>> 
>>> Interesting thoughts, Ertugrul.  I would argue that you can get very
>>> serious with Haskell without understanding applicative functors and
>>> the function arrow.  The very basic aspects of the language (the type
>>> system, higher-order functions, lazy evaluation, etc…) are already so
>>> powerful, that you really don't need to add complexity to simple
>>> programs by including some of the more obscure extensions.  I could
>>> see if it made the code substantially more compact.  In this case, it
>>> makes the code more verbose as you need to import the two modules to
>>> do something which can be so trivially expressed as an abstraction.
>> 
>> Haskell application development is more than just the language.  The
>> language itself is very powerful, yes, but serious applications I write
>> usually have quite a few dependencies.  If you want to reinvent the
>> wheel for everything, then yes, I'm exaggerating.  Personally I don't
>> want to, because there are great libraries and design patterns out
>> there, for which you simply need to understand more than just the
>> language.
>> 
>> It's as simple as this:  To get serious with Haskell, you need to
>> understand Haskell monads.  Understanding them implies understanding
>> applicative functors (not necessarily the applicative style).  For many
>> of the useful libraries you will want to go further and understand monad
>> transformers and more.
>> 
>> I'm not talking about any ideals here.  I'm talking about real world
>> application development, which is what I am doing.
>> 
>> 
>>> When you write a program, do you think of it as a document only for
>>> the compiler to understand, or might some other people need to
>>> understand it someday?
>> 
>> "It"?  For me type signatures are specification for the compiler and
>> documentation for humans, along with Haddock-style comments.  My code is
>> usually very well documented.  In most cases Haddock shows me a coverage
>> of 100% for all of my source files, and every top-level and
>> 'where'-definition has a type signature.  I'm very rigorous here.
>> 
>> All of the power I get from Haskell itself, the base library and the
>> many libraries I use I view as tools to get stuff done quickly, safely
>> and elegantly.  As said, there is always a simpler way to write stuff,
>> but I have a certain style, which I follow consistently, and in that
>> style I write 'second pure'.  That's it.
>> 
>> Why not '(:[])'?  Simply because I hate it and find it confusing.  Why
>> not 'return'?  Because I write my code reasonably general.  Not that
>> using 'return' would change the type signature in question, but it is
>> just my style.  In a do-block I use 'return'.  Everywhere else I use
>> 'pure'.  Consistently.  Why 'second'?  Because it's convenient.
>> 
>> 
>> Greets,
>> Ertugrul
>> 
>> 
>> --
>> nightmare = unsafePerformIO (getWrongWife >>= sex)
>> http://ertes.de/
>> 
>> 
>> 
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://www.haskell.org/mailman/listinfo/beginners
>> 
> 
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20110724/57e1481e/attachment-0001.htm>