>3. Don't modify parameters. It makes code easier to test in any language.

It's not about modifying parameters. It's about verbosity of the code. The type of the parameter is IO String.

>5. GHC may as well be the standard. Are you really going to use a different compiler.

It's a real issue. Different language extensions might modify how type inference works. If you add one more extension, you program might suddenly stop to compile. We need a fixed set of language extensions which are always available.

> If you add one more extension, you program might suddenly stop to compile.

Do you have some real examples of this happening with GHC extensions? I haven't run across one in the field.

> We need a fixed set of language extensions which are always available.

This sounds very much like a language standard. Haskell isn't much different than other languages here, though the language committee is slow to ratify generally accepted extensions into the standard. GHC at least makes them available to people who want to kick the tires. Then read about closures in Java. Look at C++11 revisions and notice that sometimes meant cutting features, even if they were previously implemented by some compilers (template exports) or prototyped (concepts).

>Do you have some real examples of this happening with GHC extensions? I haven't run across one in the field.

I am not that advanced in how GHC types work. However, I understand, that in any language extensions there are tradeoffs between how expressive a language is and how much type inference we have.

Many (most?) of GHC's commonly used language extensions enable new functionality or syntax (DataKinds, GADTs, RankNTypes, KindSignatures, TypeFamilies, FunDeps, MPTCs, etc). Enabling such extensions and not using these newly enabled features shouldn't affect type inference.

3. in general haskell is even terser then i like.

5. What on earth are you talking about? Conjecturing about type inference is not useful. While I may prefer some extensions to be on be default, in hundreds of thousands of lines of haskell code I am yet to see adding an extension break existing code. The worst I have seen is adding an extension slow down compilation.

In haskell you have to forget most of what you have learned in order to be successful. Otherwise you will fight the language.

> 3. in general haskell is even terser then i like.

It's the same kind of terseness that languages like Perl have. It's write/only code.

I have not found that to be true.

> The type of the parameter is IO String.

No, the type of the parameter is String. IO String is the type of the expression that gets that parameter when executed. There's a popular quote by shachaf, "getLine :: IO String contains a String in the same way that /bin/ls contains a list of files" that illustrates this nicely.

I understand what a monad and IO monad is and what the types of the expressions are. I am just showing that the current monad syntax is ugly. connectToDb $ readParams "conf" can be transformed by a compiler into what you wrote.

readParams "conf" >>= connectToDb