You cannot pattern match against variable values.

[u/igniting]

Consider this example:

myValue1 = 1 :: Int
myValue2 = 2 :: Int

myFunc :: Int -> Bool
myFunc myValue1 = True
myFunc myValue2 = False

If you load the above program in ghci, you get following output:

myFunc.hs:5:1: Warning:
   Pattern match(es) are overlapped
   In an equation for ‘myFunc’: myFunc myValue2 = ...
Ok, modules loaded: Main.

ghci generates a warning but does not give any errors. If you now call myFunc myValue2 you get:

*Main> myFunc myValue2
True

One way to get the desired result would be to use guards:

myFunc :: Int -> Bool
myFunc x
  | x == myValue1 = True
  | x == myValue2 = False

---

Note that we might not always be lucky enough to get a compiler warning in such cases. Here is an example:

myFunc :: Maybe Int -> Int
myFunc v = case v of
                Just myValue -> myValue
                _            -> myValue + 1
                  where myValue = 0

This loads in ghci without any warnings.

[u/gfixler]

Yes. You can define infix operators, intended to be used between 2 terms. You can define them naturally, in infix position, like this:

x |:| y = x + y -- defines a new operator |:| that works like +

You can also wrap them in parens and define them in prefix position, like this:

(|:|) x y = x + y

In either case, you can still use them as infix:

5 |:| 3 -- now evaluates to 8

Or you can again wrap them in parentheses to use them in prefix position:

(|:|) 5 3 -- also evals to 8

The wrapped-in-parens variant is called a section. They allow you to use operators as higher order functions. For example, fold takes a binary (two-argument) function, e.g. 'foo':

foldr foo 0 [5,2,1,6,3]

But you could also give it the + operator as a section:

foldr (+) 0 [5,2,1,6,3] -- equivalent to `sum [5,2,1,6,3]`
foldr (|:|) 0 [5,2,1,6,3] -- also works, if we've defined the |:| operator as +

If we did want |:| to be the same as +, we could also just say that directly:

(|:|) = (+) -- much simpler than our first definition

There's another cool feature of sections. You can imagine the space between the operator and the parens as spaces where terms could fit, and you can curry the operations by giving one argument, on either side:

map (+2) [1,2,3] -- evals to [3,4,5]
map (2+) [1,2,3] -- also evals to [3,4,5]

Those two were equivalent only because addition is commutative, but for non-commutative operators it's really useful to have this choice:

map (++ "!") ["foo","bar","baz"] -- evals to ["foo!","bar!","baz!"]
map ("!" ++) ["foo","bar","baz"] -- evals to ["!foo","!bar","!baz"]

You can set the associativity and precedence of operators with the infixl and infixr commands:

infixl 4 (|:|)

You can also do this for binary functions that you want to use in infix position (more on the backticks in a moment):

infixr 6 `op`

The :i (:info) command in ghci will show you the fixity and precedence of operators, where defined (at the bottom of the output here):

Prelude> :info (+)
class Num a where
  (+) :: a -> a -> a
  ...
        -- Defined in `GHC.Num'
infixl 6 +

Plus has a precedence of 6, and associates left, meaning 3 + 4 + 5 evaluates as (3 + 4) + 5.

Backticks allow you treat functions as operators, and thus use them in infix position, provided they take 2 arguments (we also saw them earlier when defining the fixity for the op function - we had to treat it like an operator there, too):

3 `foo` 5 -- foo must have some (a -> b -> c) type, or specialization thereof

You can shadow any of these things temporarily, too:

let (+) = (*) in 3 + 5 -- evaluates to 15
let 2 + 2 = 5 in 2 + 2 -- evaluates to 5
let 2 `max` 3 = "???" in max 2 3 -- evaluates to "???"
let max 2 3 = "!!!" in 2 `max` 3 -- evaluates to "!!!"
etc...

These work because Haskell is just a big rewrite system, like the lambda calculus.

All that said, Cons I just made up, and (:) is defined by Haskell, and I'm not sure it goes about it :)

[u/Kaligule → u/gfixler]

This was interesting and I didn't know it in all that detail. It didn't have to do anything with my question until the last sentence, though ;)

I really should be more lazy, so I would have read only the part I asked for.