| b = x would be fine. Straight pattern matching is another possibility, but it's mostly a matter of taste.

I wouldn't worry too much about any difference between case, if and | expressions and pattern matches. After desugaring, there's probably no appreciable difference anyway. I would be not at all surprised if most solutions generate exactly the same bytecode in the end.

That being said, learn the syntax first, how to interpret the error messages as best you can - write clean code later, you can always refactor.

Haskell is about expressions, guards are just IF blocks, in general

boolValue = True
if boolValue == True then "It is true" else "It is false"

would normally just be

boolValue = True
if boolValue then "It is true" else "It is false"

Thanks for the feedback! I was using Codewars to help learn Haskell so I'm not surprised my solution isn't great. Is | b = x valid or do you have another suggestion. Thanks again.

b == True is an antipattern.

This kata (unhelpfully) omits leading and trailing zeros from the input array.
It makes more sense if you consider that [1] as provided, is actually [0,1,0]

I don't see how with 1 iteration the rule goes from [1] to [1, 1, 1]. I understand that since 1 is next to both borders of the list that we add in 0 to both sides of the 1 which gives us [0, 1, 0], but how do we then get [1, 1, 1] from that? Do we change all cells under consideration to the value in the new cell row? That is, since was have [0, 1, 0] and the rule says 1, both left neighbor, current cell, and right neighbor all become one? The way its worded it sounds like only the current cell changes, which in the case of [0, 1, 0] its already a one so we should just stay [0, 1, 0] not become [1, 1, 1].

This is so elegant it made me feel bad about my solution. Nice work.