CODEWITHSUNDEEP
haskellcoding-styleoperatorstypeclass
bdhar
bdhar

Reputation: 22983

null instead of ==

I have just started to learn Haskell out of interest. I follow learnyouahaskell.com.

There I found this:

null checks if a list is empty. If it is, it returns True, otherwise it returns False. Use this function instead of xs == [] (if you have a list called xs)

Why is that? Why should we use null instead of == when both produce the same result?

Thanks.

Upvotes: 37

Views: 17049

Answers (3)

John L
John L

Reputation: 28097

Another benefit to using null is that many other containers (e.g. Data.Sequence, Data.ByteString, etc.) have a null function as well. This makes it easy to switch to another implementation simply by changing your import statements.

Upvotes: 6

Thomas
Thomas

Reputation: 182000

In my opinion, null myList reads more naturally than myList == [].

But the raison d'être for null is that it can be used as a function. For example, here's a function that takes a list of lists, and returns only the nonempty ones:

nonemptyLists :: [[a]] -> [[a]]
nonemptyLists = filter (not . null)

Without null, this would be more awkward:

nonEmptyLists = filter ([] /=)

Upvotes: 11

sdcvvc
sdcvvc

Reputation: 25654

Comparing the lists with == requires elements to be comparable (denoted as Eq a).

Prelude> :t (==[])
(==[]) :: (Eq a) => [a] -> Bool

For example, [sin] == [] won't work, since you can't compare functions. It might seem stupid, but the type system must judge type of an expression without looking at its value.

An alternate check would be length xs == 0, this doesn't require equality but won't stop if your list is infinite (try length [1..] == 0). That's why there's a dedicated function.

null [] = True
null _ = False

Prelude> :t null
null :: [a] -> Bool     -- Notice lack of (Eq a).

Upvotes: 72

Related Questions