Dennis Raddle wrote:

Another problem is have is to filter entries in a map. If I have a map

Ord k => Map k [a]

(essentially, which combines data with the same key into a list)

and I have a predicte (k,a) -> Bool

(which takes the key and one element in its list and checks it)

and I need to regenerate the map, what would be a good way to do that?

See the foldWithKey function in Data.Map. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

I understand your point, but the spirit of Haskell as I have encountered it (as a beginner, reading Typeclasspedia and other sources) would be - Of course you need to learn about arrows and applicative functors.You need to do that anyway. - The expression "map (second pure)" is simpler in the sense it has fewer moving parts, and it's worth understanding how to read it and how to write things like it That's how I understand the spirit of Haskell, although I could have a limited perspective. Dennis On Sat, Jul 23, 2011 at 5:44 AM, David Place wrote:

On Jul 22, 2011, at 10:58 PM, Ertugrul Soeylemez wrote:

...

fromAmbList :: Ord k => [(k, a)] -> Map k [a] fromAmbList = M.fromListWith (++) . map (second pure)

If I am reading your code, I may look up second and find it in Control.Arrow. I have to learn about Arrows to understand your code? And pure makes me need to study the Applicative class. I imagine that it is likely that second is the only thing from Control.Arrow that you are using and pure is the only thing from Control.Applicative. So, you need two lines of extra code to express what could be expressed much more perspicuously as:

...

fromAmbList :: Ord k => [(k, a)] -> Map k [a] fromAmbList = M.fromListWith (++) . map (\(k,v) -> (k,[v]))

On Sat, Jul 23, 2011 at 6:25 AM, David Place wrote:

On Jul 23, 2011, at 9:17 AM, Dennis Raddle wrote:

That's how I understand the spirit of Haskell, although I could have a limited perspective.

I think this is a valid point of view, but needs to be balanced by a need for perspicuity. After all, you aren't really using Arrows. It's just a coincidence that this function does what you want on a concrete implementation level.

"Coincidence"? "Not really using arrows"? What I've learned from Haskellers is that it marvelous how we can find useful instances of the important types. What I've been taught is to celebrate that by using every useful instance.

On Jul 23, 2011, at 5:46 PM, Ertugrul Soeylemez 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. 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? ____________________ David Place Owner, Panpipes Ho! LLC http://panpipesho.com d@vidplace.com

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 wrote:

David Place 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@haskell.org http://www.haskell.org/mailman/listinfo/beginners

I understood your code and I agree it's elegant. On Sun, Jul 24, 2011 at 8:44 AM, Julian Porter wrote:

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-... for a description.

*Julian Porter julian.porter@porternet.org **http://www.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 wrote:

David Place 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@haskell.org

http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Ertugrul Soeylemez wrote:

...

  fromAmbList :: Ord k => [(k, a)] -> Map k [a]    fromAmbList = M.fromListWith (++) . map (second pure)

David Place wrote:

If I am reading your code, I may look up second and find it in Control.Arrow. I have to learn about Arrows to understand your code?  And pure makes me need to study the Applicative class.

For this, there is no need to get into the issue of when is the right time to learn about Arrows and Applicative. The functions "first" and "second" from Control.Arrow are quite common in Haskell. They are simple and convenient, they don't require knowing anything about Arrows when used with plain old functions and tuples, and using them doesn't create any library dependencies. Whether or not you use them in your own style is your own choice (I have gone through different periods either way, currently I don't use them much), but it's a good idea to be familiar with them. Here are their type signatures, translated into the usual non-Arrows style: first :: (a -> a') -> (a, b) -> (a', b) second :: (b -> b') -> (a, b) -> (a, b') As for "pure", my opinion is that it's not very good style to use it in this context. We're not using the Applicative structure of lists in any significant way here, we're just creating singleton lists. So I would just use (: []). That said, "pure" is also very simple. For lists, we have: pure = return = (: []) -- for lists only Another simple but useful Haskell fact. -Yitz

If I am reading your paragraph, I may look up 'perspicuously' and find it in the dictionary.  I have to learn about this word to understand your paragraph?  You need three extra syllables to express what could be expressed much more clearly as: 'So, you need two lines of extra code to express what could be expressed much more clearly as:'.

Reminds me of an anecdote on George Orwell's writing style I found as part of an NPR article[1]: A scrupulous writer, Orwell notes, will ask himself: What am I trying to say? What words will express it? What fresh image will make it clearer? Could I put it more shortly? Have I said anything that is avoidably ugly? The alternative is simply "throwing your mind open and letting the ready-made phrases come crowding in. They will construct your sentences for you — even think your thoughts for you — concealing your meaning even from yourself. It is at this point that the special connection between politics and the debasement of language becomes clear." -deech [1] http://www.npr.org/templates/story/story.php?storyId=6124822

Lifting to the List monad gives a very elegant solution: listOutMap :: k -> [a] -> [(k,a)] listOutMap x ys = liftM2 (,) (return x) ys Julian Porter julian.porter@porternet.org http://www.porternet.org On 23 Jul 2011, at 15:08, Christian Maeder wrote:

Am 23.07.2011 03:40, schrieb Dennis Raddle: ...

...

listOutMap :: Ord k => Map k [a] -> [(k,a)] listOutMap m = concatMap (\(k,a) -> zip (repeat k) a) (M.toList m) ...

instead of "zip" and "repeat" I prefer just "map":

"\ (k, as) -> map (\ a -> (k, a)) as"

(and don't bother to switch on TupleSections for "(k,)")

C.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners