4 ms·

So, you recognize imperative is a subset of functional? :-P do-blocks have perfectly functional semantics, so if you consider that to be imperative as well, th

So, you recognize imperative is a subset of functional? :-P do-blocks have perfectly functional semantics, so if you consider that to be imperative as well, this means that a sequence of instructions changing state is both imperative and functional, as long as you declare where the state is being handled in your code. And yes, of course functional code can handle state. The good thing about this 'Haskell imperative' style is that it doesn't fall prey of side effects, the bane of imperative programs (uncontrolled side effects are NOT a good thing). In Haskell, you control why and where you allow them.

jcelerier 5y ago
One could also make a language that has exactly the same visual syntax that C where ; is specified as a functional composition operator instead of a separation of instructions. These kind of mindgames are pointless - if your code is sequencing instructions, it's imperative ; if it's denoting it's functional
- TuringTest 5y ago
  If you do that, then you have to admit different kinds of imperative code: C-imperative style that can modify any state in the application as side effects, and Haskell-imperative where you can only modify state explicitly declared as input to the procedure. It's not just mind games, the difference has very real implications to the architecture of the whole program and the control you can exert over unpredictable side errors.