It's a good idea to use [Char] instead of String in a Haskell function type declaration.

Question

I just started learning Haskell using "Learn you a Haskell for Great Good." I am currently reading the chapter "Types and Typeclasses", so my knowledge is pretty ... do not exist. I am using Sublime Text 2 with the SublimeHaskell package, which builds / validates a file each time it is saved.

Problem: I'm trying to make a function type declaration like this:

funcName :: [Char] -> [Char] 

I get this warning:

Warning: use String Found: [Char] → [Char] Why not: String → String

FAILED assembly

Can you explain to me why it is a bad idea to use a Char array instead of a String or give me a link to explain the possible consequences, etc. I googled and found nothing.

PS I am a C # developer, I understand the difference between a 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 the documentation selection. I often define type aliases as follows:

 type Domain = ByteString type UserName = Text 

It is recommended to use types for documentation.

Just like the important side of a note, [Char] is not a type of character array, but a list of characters. Since there are also real types of arrays, this is important!

Answer 2

String is nothing more than a type alias for [Char] , so there's nothing practical between them - it's just a readability issue.

Answer 3

It seems you run HLint on your code automatically and treat any HLint warnings as fatal errors. As the author of HLint says, "Don't blindly apply HLint output." String and [Char] exactly the same as everyone says, this is a question that looks better. I would like to use String if I work on contiguous lists of characters that I want to treat as a block (most of the time), and explicitly use [Char] when the characters don't make sense combined in the race (much less often). HLint divides all the error hints (correction) and warning (I think), so it might be best to build errors on errors.