2

I suppose most purely functional programming languages have feature to control side-effects in function, such like monads in Haskell, but Elm doesn't require such feature due to TEA. Moreover, I hear Nim is an impurely functional programming language but it separates func and proc by with/without side-effects.

Then, I have a question. Is there any list of programming languages categorized by can or can't control side-effect in function? If not, could you give me some names of languages? I will search for name and study how it work, but I'm glad you to write it simply if possible. Following is list I know languages which can control side-effects and its way:

  • by monad
    • Haskell
    • PureScript
    • Idris
    • (After looking up some similar languages, I suppose Agda and Isabelle are included)
  • by algebraic effects (I don't understand it well)
    • Koka
    • Eff
  • by type
    • Clean
  • by syntax
    • Nim - proc and func

In addition, please let me know documents about controlling side-effects in function if you know.

Akihito KIRISAKI
  • 1,243
  • 6
  • 12
  • The StackOverflow platform is not well suited for questions that ask for lists. – Bergi Dec 06 '20 at 12:34
  • 1
    Btw, to clear up some confusion, [Haskell doesn't need monads to achieve IO](https://stackoverflow.com/a/28141248/1048572). And most algebraic effects compose monadically as well. I would suggest you study those a bit more, as well as the papers about IO of the Haskell creators. – Bergi Dec 06 '20 at 14:52
  • Will the article contain the links to the papers? Anyway I will read it thoroughly, thanks! – Akihito KIRISAKI Dec 06 '20 at 23:53
  • 1
    Possibly related: https://stackoverflow.com/questions/8666618/possible-means-of-side-effectst-in-purely-functional-languages . – atravers Dec 25 '20 at 22:34
  • Elm does not "avoid" monads. It uses them everywhere, it just does not mention them by name and it has terrible language support for them – saolof Jun 20 '21 at 08:53

1 Answers1

-1

Nope, your categorization is all wrong.

Haskell does not need IO to introduce side-effect and it can be easily done bypassing it. It also has error "Oops" concept that is not bound to IO a and can be used within pure functions. For example following definition is perfectly valid Haskell code:

myDiv1 :: Float -> Float -> Float
myDiv1 x 0 = error "Division by zero"
myDiv1 x y = x / y

More than that, you do not need any monad to handle an error. Consider Go with it's annoying

res1, err := somePackage.SomeOperationThatMightEndWithError()
if err == Nil {
    // do something with it
}
res2, err := somePackage.SomeAnotherDangereousOperation(res1) 
if err == Nil {
    // do something with it
}

It is not a monad. But it approaches purity by explicit error handling all over the codebase.

The same way of thinking can be applied to other categories you decided to list in the original post.

Zazaeil
  • 3,900
  • 2
  • 14
  • 31
  • 1
    How does a Haskell program do side effects without `IO`? Sure, you can bypass proper techniques with `unsafePerformIO` in the same way you can write partial functions with `error` that just crash your program, but none of this changes the fact that Haskell's choice for controlling side effects is the `IO` monad. – Bergi Dec 07 '20 at 13:27
  • @Bergi, first of all, (almost) any function that returns `IO a`, i.e. ends with `-> IO a` arrow, is **pure**. That's what meant to be said by the `pure :: a -> IO a` definition actually. Secondly, as far as runtime permits "partial functions", stack-winding exceptions at any point of execution and dirty hacks like `unsafePerformIO`, `IO`-monad is no longer "Haskell's choice" as you wrote, but programmer's choice. Or standard library's choice. But not runtime's choice. – Zazaeil Dec 07 '20 at 13:43
  • So what you're saying is that GHCs runtime is impure? Bummer. – Bergi Dec 07 '20 at 14:01
  • @Bergi I am saying literally what is written in my post and comments :) whether you like Haskell or not, whether you adopt `IO` or not, you still allowed to bypass `IO` **easily** and break functions that appear to be pure by their signature. No offense, it is what it is. – Zazaeil Dec 07 '20 at 14:09
  • I disagree that allowing *hacks* to bypass the standard approach to controlling side effects does invalidate the OPs categorisation. – Bergi Dec 07 '20 at 14:12
  • @Bergi hacks? Those examples are taken from official documentation. And if you would one day dig into the `Prelude`, you will find those used time-to-time. Thus, with respect to math and `IO` concept such techniques are nothing but "dirty hacks" indeed, but not for Haskell, nor for `Prelude`. Seems you try to extrapolate your personal preferences and idealism. Once again, sorry to disappoint you. – Zazaeil Dec 07 '20 at 14:16
  • Hmm... I could understand `error`, partial functions, `unsafePerformIO` and so on can destroy Haskell's purity. But the example which @SerejaBogolubov gave in Go can be destroyed its purity easily by `panic`. Even Elm has bypass functions like a Debug.log. How about Nim? Or as you said, the categorization is all wrong? Even if so and it's a fuzzy categorization, I think it's interesting to categorize by whether languages try to control side-effects. – Akihito KIRISAKI Dec 10 '20 at 18:10
  • @AkihitoKIRISAKI it "all wrong" simply because it does **not** categorize languages themselves, but (at best) their standard libraries written in this or that fashion. Eventually, it categorizes **communities** and their believes. Imagine one day some powerful JS library will pop up heavily relying upon `Either a b`, would that mean that it's JavaScript feature? It's better to say how language syntax helps or does not help to introduce some concepts, for example Haskell and Scala do have specific syntactic sugar to benefit from monads and JavaScript does not. – Zazaeil Dec 11 '20 at 08:28