Ambiguity.hs

-- Explicitly stating the order of computation `a (b c)` makes this not compile
-- While, if we used a C style, order of computation would be explicit by default `a(b(c))` vs `a(b, c)`
example1 = a b c
    where
        a first second = first ++ second
        b = "hey"
        c = " world"

-- Explicitly stating `a (b c)` makes this compile
example2 = a b c 
    where
        a str = str
        b str = "hey" ++ str
        c = " world"

-- But we can create an unambiguous version of the function using tuples!
example3 = a(b, c)
    where
        a(first, second) = first ++ second
        b = "hey"
        c = " world"

main = do
    putStrLn example1
    putStrLn example2
    putStrLn example3

What I think is also tripping you up is that, while Haskell has a pair type, and you can write:

example1 = a ("hey", " world")
   where a (b, c) = b ++ c  -- we can also write a = uncurry (++)

OH MY GAWD

I was thinking about it more, and a problem with C-style is operators are an exception, because you obviously don't write (123)+(321) ... that just looks weird. Also, like you said things like if ... then ... else ... could be thought of as a series of functions.

Taking another look, Haskell style is really a super set of C-style, because as you demonstrated, you can replicate that style within Haskell! So an explicit set of arguments should be looked more as a type, being a tuple! Mondo cool.

---

There is however an ambiguity in evaluation order here

This is my favorite part of Haskell! I love how it feels like I'm programming from left to right, not top to bottom.

Not sure what the proper term for order of computation is, perhaps the correct way for what I'm trying to say is: ambuguitiy in function application ... which is conceptually different to me than evaluation order.

Thanks for the amazing response! You completed the puzzle in my head, ♡ #haskell. If something I said sounds wrong please school me again.