Is it a bad idea to use [Char] instead of String in Haskell function type declaration

Question

I have just started learning Haskell using "Learn you a Haskell for Great Good". I am currently reading "Types and Typeclasses" chapter, so my knowledge is pretty .. non-existent. I am using Sublime Text 2 with SublimeHaskell package which builds/checks file on every save.

The problem: I'm trying to make function type declaration like this:

funcName :: [Char] -> [Char]

I'm getting this warning:

Warning: Use String Found: [Char] -> [Char] Why not: String -> String

Build FAILED

Can you explain to me why is it a bad idea to use Char array instead of String or give me a link to an explanation of possible repercussions etc. I've googled and found nothing.

P.S. I'm a C# developer, I understand the difference between char array and strings in c-like languages.

Answer 1

Somewhere in the base library you will find this definition:

type String = [Char]

which says that String and [Char] are exactly the same thing. Which of the two you choose is a documentation choice. I often define type aliases like this:

type Domain = ByteString
type UserName = Text

It's a good idea to use types for documentation.

Also as an important side note, [Char] is not the type for character arrays, but character lists. Since there are also actual array types, the distinction is important!

Answer 2

String is nothing more than a type alias for [Char], so there is no practical between the two - it's simply a matter of readability.

Answer 3

You seem to be running HLint on your code automatically, and treating any HLint warnings as fatal errors. As the HLint author says "Do not blindly apply the output of HLint". String and [Char] are exactly the same, as everyone says, it's a question of which looks nicer. I would tend to use String if I'm operating on contiguous lists of characters I want to treat as a block (most of the time), and explicitly use [Char] when the characters don't make sense combined in a run (far rarer). HLint divides all hints into error (fix) and warning (think), so perhaps it might be best only to build fail on error hints.