[Haskell-beginners] a problem with maps
julian.porter at porternet.org
Sun Jul 24 17:44:55 CEST 2011
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 at porternet.org
On 24 Jul 2011, at 01:13, aditya siram wrote:
> 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
> 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.
> 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
>> 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.
>> nightmare = unsafePerformIO (getWrongWife >>= sex)
>> Beginners mailing list
>> Beginners at haskell.org
> Beginners mailing list
> Beginners at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Beginners