We could debate this endlessly (as is common), but I would argue that a "clean" design would make the option and alternative of multiplying explicit in its design instead of including calls to fetch command line arguments in an ad-hoc fashion everywhere.

The Haskell way of encoding this would be to define an app configuration data type (say AppConfig), parse the command line arguments into it upfront in IO and then run your application either in a in a monad that's an instance of (MonadReader MyConfig) or explicitly pass the option in where needed by a function. If you've designed your application this way, adding a new command line option would cause very little -if any- refactoring. If not, in my experience it is usually a 30 minute intense refactoring campaign.

I suspect there might be a way to use implicit arguments here as well, but that's something I've never felt compelled to use.

This kind of separation of concerns and "pure" application design is one of the things that (I think) many people really like about Haskell.

Hi,

MightyByte wrote:

Of course every line of your program that uses a Foo will change if you switch
to IO Foo instead.

But we often have to also change lines that don't use Foo at all. For

example, here is the type of binary trees of integers:

data Tree = Leaf Integer | Branch (Tree Integer) (Tree Integer)

A function to add up all integers in a tree:

amount:: Tree -> Integer

amount (Leaf x) = x

amount (Branch t1 t2) = amountt1 + amountt2

All fine so far. Now, consider the following additional requirement: "If

the command-line flag --multiply is set, the function amount computes

the product instead of the sum."

In a language with implicit side effects, it is easy to implement this.

We just change the third line of the amount function to check whether to

call (+) or (*). In particular, we would not touch the other two lines.

How would you implement this requirement in Haskell without changing the

line "amount (Leaf x) = x"?

(I actually see three ways of doing this in Haskell, but all have

serious drawbacks and do not fully solve the problem).

Here it seems not so bad just to change all three lines of the amount

function, even if they are not strictly related to the semantic change

we want to make. But in a real program, this situation can translate to

changing thousands of lines of code in many functions just to implement

a minor change to a single requirement.

Tillmann

_______________________________________________

Haskell-Cafe mailing list

Haskell-Cafe@haskell.org

http://www.haskell.org/mailman/listinfo/haskell-cafe