Luckily, the vast majority of FP languages operate on lists of procedures combined together with the `.` operator. Similar to how C composes things with the `;` and many pythonic languages compose with the newline operator.
Realistically, most FP programmers program ML-like languages (Haskell and Elm included) in an imperative manner. It's an extremely straightforward translation, and in Haskell it's basically syntactically identical due to do notation.
I'm not talking about tricky stuff like do syntax monads.
I'm talking about FP at it's core.
The '.' compose operator is not procedures. In haskell it does something completely different.
>Realistically, most FP programmers program ML-like languages (Haskell and Elm included) in an imperative manner. It's an extremely straightforward translation, and in Haskell it's basically syntactically identical due to do notation.
No Elm doesn't do any tricky stuff. So elm is not imperative Haskell can look imperative with do notation. That's about it.
I mean you can put put elements of your equation on different lines but it's still not imperative.
1 +
2 +
3
I mean ..yeah... if you want to call that (1 + 2 + 3) imperative, be my guest. But obviously that's not what I'm talking about.
Function composition is the most basic thing in FP languages and is equivalent in spirit and nature to the semicolon or newline operators of c and python like languages. Not sure why you chose addition as an example. Addition is order independent in most languages.
In elm (not 100% familiar with the operators), ordered compute can be expressed as follows:
a >> b >> c
Which says do a first, then b then c. Due to how data deps work in an FP language, a is always done first here, b next and c last.
Very imperative. No do notation.
In fact all the major Haskell monad instances are variations of the (.) operator, including IO.
So... If ordered compute extending all the way to IO is not what you're talking about... What are you?
Composing things with the dot doesn't execute anything.
It creates a new function. In Haskell it's actually composed backwards. The first function executed after you compose your function and apply that function is to the right.
Additionally each composition must have inputs and outputs that match the neighboring functions.
Nobody thinks this way when writing procedures. Each instruction is independent of the other. Composition is about building a pipeline, very very not imperative.
Do notation in Haskell is the closest thing in go to imperative. It is not composition. It's just an series of endlessly nesting closures which technically is even more harder to reason about. Do notation unravels this in ways that are hard to understand what's truly going on.
The point is this. Haskell and elm are not imperative, at times they can imitate imperativeness but to deal with these languages 100 percent involves thinking differently in ways that are unnatural. No amount of bending and breaking is going to turn these languages into something you can call imperative.
Yeah and composing things with a semicolon creates a new c program
Haskell is an expression language and a runtime environment. The expression language is more powerful than c, but c et al are also expression languages plus environments, just not typically talked about that way. Because the expression language is quite simple.
Imperative do this then that is a exactly function composition where the pipeline is the state. In other words imperative languages provide an implicit function. This is most obviously seen with stack based concatenative languages.
Realistically, most FP programmers program ML-like languages (Haskell and Elm included) in an imperative manner. It's an extremely straightforward translation, and in Haskell it's basically syntactically identical due to do notation.