Not exactly answering your question, but here's the top refactorings that I'd like to see in a Haskell IDE: * rename identifier (aware of scopes, modules, qualified imports etc.) * move definition from one module to another (aware of ...) * change "type" to "newtype" or "data" * change positional to named record notation * introduce parameter (to function) (with a default value that is plugged in at each call site) * change order of parameters * introduce parameter object That's the kind of basic rewriting that is really really awkward to do with a plain text editor (because you really need the annotated AST, with names resolved, and types attached) - so it's usually avoided (well, by me) and the result is code that is a nightmare to maintain.

On Tue, Mar 02, 2010 at 08:20:30PM +0100, Sean Leather wrote:

There are numerous threads on the Haskell Café involving rewriting, refactoring, refining, and in general improving code (for some definition of improve). I am interested in seeing examples of how Haskell code can be rewritten to make it better. Some general examples are:

One handy manual transformation is trying to do more checks on the typechecker. GADT's + phantom types are very useful!

x >>= return . f --> fmap f x or f <$> x -- requires importing Control.Applicative

I think the right-hand side (RHS) is more concise and simpler. The types here do change: the type constructor has a Monad constraint in the left-hand side and a Functor constraint in the RHS. Types that are Monad instances are generally also Functor instances, so this is often possible. I'm convinced the semantics are preserved, though I haven't proven it.

Yes, they are the same, always. -- Felipe.

Speaking about macrorewriting, I do prefer to break big modules (prototypes) into smaller ones, then step by step separate them into a set of minimally dependent and highly general cabal packages. As for microrewriting I find it to be a good practice to explicate all possible (programmable or Real World) errors into dedicated ADT constructions. This draws enough attention to every error to guarantee that there is no missed risks and protection is good enough. Regards, Andrey -- View this message in context: http://old.nabble.com/How-do-you-rewrite-your-code--tp27760033p27760681.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

On 2 March 2010 19:20, Sean Leather wrote:

My question is simple:

   How do you rewrite your code to improve it?

Hi Sean - excellent question! Some things I do... Quite often I do a 'worker-wrapper-lite' rewrite i.e. change a function to perform its recursive work in a step rather than calling the function again with all the arguments, e.g.

para :: (a -> ([a], b) -> b) -> b -> [a] -> b para phi b = step    where step []     = b          step (x:xs) = phi x (xs, step xs)

rather than...

para_ :: (a -> ([a], b) -> b) -> b -> [a] -> b para_ phi b []     = b para_ phi b (x:xs) = phi x (xs, para_ phi b xs)

I'm doing no type changing to improve efficiency so it isn't a real worker-wrapper, but I usually find the 'step' style more pleasing, especially when the code is somewhat more complicated than the paramorphism above. Another one is to eliminate do-notation, generally I do this by using the liftM2 family more appropriately, sometimes by using my own monadic combinators - for instance quite a few operators in Control.Exception are useful for other monads rather than IO so I've versions with more general types in the Utils module that add to my projects once they get above a certain size. Generally my types change only when I realize I hadn't got them right in the first instance. I can't think of instances where I've generalized types to make them functors and so could use Traversable, Foldable... But I have had a couple instances where I've needed to change the type of a 'leaf' in a structure so realized that the containing structure was obviously a functor. Best wishes Stephen

Something I've been doing a lot lately is selective defunctionalisation, transformation into continuation passing style, and the combination of both things (CPS followed by defunctionalising the continuations). This is probably because I'm playing around with lambda calculus evaluators a lot though :-) (see Olivier Danvy's homepage for more: http://www.cs.au.dk/~danvy/) Cheers, Max On 2 March 2010 19:20, Sean Leather wrote:

There are numerous threads on the Haskell Café involving rewriting, refactoring, refining, and in general improving code (for some definition of improve). I am interested in seeing examples of how Haskell code can be rewritten to make it better. Some general examples are:

Eta-reduce Make more pointfree Introduce monadic operators or do-notation

e.g. for Maybe, lists, State

Eliminate monadic operators or do-notation Generalize types

e.g. change map to fmap, (++) to mappend

Use instances of Functor, Applicative, Alternative, Category, Arrow, Monoid, Traversable, etc. Use library functions from Data.List, Data.Map, Data.Set, etc. Use some form of generic programming (e.g. SYB, Uniplate, EMGM, Alloy) Use other libraries not included in the Platform

My question is simple:

   How do you rewrite your code to improve it?

You can answer this in any way you like, but I think the most useful answer is to show a reasonably small, concrete example of what your code looked like before and after. Also, please describe how you think the rewrite improves such code.

Is it better style? More useful? More efficient? Are the types (before and after) the same? Are the semantics the same? How did you prove or test equivalence? (e.g. Can you use equational reasoning to confirm the rewrite is valid? Did you use QuickCheck?)

Here is an example that I find myself doing occasionally.

For all x, f:

x >>= return . f --> fmap f x or f <$> x -- requires importing Control.Applicative

I think the right-hand side (RHS) is more concise and simpler. The types here do change: the type constructor has a Monad constraint in the left-hand side and a Functor constraint in the RHS. Types that are Monad instances are generally also Functor instances, so this is often possible. I'm convinced the semantics are preserved, though I haven't proven it.

What's an example of a rewrite that you've encountered?

Thanks, Sean

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Sean, that's certainly *the* question I try to solve too. My thoughts on this are a bit different from the answers I've seen here so far, apart maybe from the "Contracts" response. All my code, whether neat or not so neat is still way too concrete, too direct. I think the correct answer is one should try to find abstractions and not code straight down to the point. Which to me is still a really tough one, I have to admit. Günther

Sean Leather wrote:

My question is simple:

*How do you rewrite your code to improve it?*

The short answer is: I don't. Long answer: In the Haskell community there is a strong bias towards making your code as generic and abstract as possible. That's not because it is the recommended coding style (there is no official recommendation here), but simply because you can do it in Haskell and more importantly you can do it _easily_ compared to other languages, without (necessarily) making your code obscure. Genericity and abstraction are supposed to make coding more efficient, and if you understand them well, they do just that. However, there is a catch. If you do _not_ understand them well in your language, they will make you less efficient at first. As a hobby Haskell programmer of course you're happy with that, but you will get your code done slower than people, who 'just do it'. I'm someone, who likes to get things done, so I found it's best for me not to improve the style/genericity of existing code, unless there is a reason to do it. But I do improve my understanding of the language and the abstractions it provides, so in general I can say that my code is written in the best style and the highest genericity I understand.

What's an example of a rewrite that you've encountered?

For example as a beginner, when I didn't understand the list monad or how folds work, my implementation of the 'subsequences' function looked like this: subsets :: [a] -> [[a]] subsets [] = [[]] subsets (x:xs) = ys ++ map (x:) ys where ys = subsets xs When I started to comprehend folds, the function started to look more like this: subsets :: [a] -> [[a]] subsets = foldr (\x xs -> xs ++ map (x:) xs) [[]] Finally now that I understand the list monad very well, my implementation looks like this: subsets :: [a] -> [[a]] subsets = filterM (const [True, False]) Or even like this: subsets :: MonadPlus m => [a] -> m [a] subsets = filterM (const . msum . map return $ [True, False]) Note that I have never rewritten an existing 'subsets' function and today I would just use Data.List.subsequences, which was added recently. So my conclusion is: In production code don't worry too much about it, just write your code and don't stop learning. If your code works and is readable, there is no need to make it look nicer or more abstract. If you have to rewrite or change the function, you can still make it better. The exception is: If you code for fun or exercise, there is nothing wrong with playing with abstractions and enhance your skills in a funny way. As a side note: I have found that many people don't understand the filterM-based solution. That's because many people don't understand the list monad and the power of the monadic interface. So if you work in a group, either don't write code like this or preferably explain monads to your groupmates. Greets Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/