# Should Haskell be rebranded away from "Pure Functional Programming"

**URL:** <https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850>\
**Category:** Uncategorized\
**Created:** [July 28, 2022, 9:19am UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850 "2022-07-28T09:19:58Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [July 28, 2022, 9:19am UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/1 "2022-07-28T09:19:58Z")

</div>

Here’s the thing, Haskell isn’t actually “pure (functional programming)”. It has support for procedural-looking code (do notation), actually mutable variables (IORef, STRef, MVar, TVar), as well as dynamic types (Dynamic, -fdefer-type-errors), and even objects, via libraries like Hoop and Objective.

What it is, instead, because of how Haskell relies on the IO monad, and GHC relies on State# RealWorld a, is “pure functional $ programming”. What you end up with is a relatively strict isolation between pure parts of your program and impure parts, which in combination with a syntax highly conducive to FP, permit what is sometimes described as algebraic programming, wherein equational reasoning holds.

> **[The Algebra of Programming](https://medium.com/techspiration-ideas-making-it-happen/the-algebra-of-programming-e0bdbc59dc65)**
>
> Have you ever stopped and thought, “Man, laws are really great!” Nope? Imagine something super mundane. How about driving to the store and buying some bread. Boring right? Now, imagine doing that…

> **[Functional Programming as Algebra](https://thoughtbot.com/blog/functional-programming-as-algebra)**
>
> Let’s return to everyone’s “favorite” subject. 🙄

The problem, though, is that the term pure creates confusion. Both Richard Bird (may he rest in peace) and SPJ have called Haskell “Imperative Functional Programming”. An astute Haskell learner, after jumping through the initial hoops, will realize that Haskell is capable of producing extremely imperative code (I have an allergy to do notation for this reason and use it very sparingly as a consequence).

Perhaps rebranding Haskell as, instead of “purely functional programming”, “algebraic programming”, “algebraic functional programming”, or “purely functional or algebraic programming” might help to avoid the confusion? The trade-offs would be that the line “pure, functional” helps attract people interested in FP for FP’s sake, but how many of them actually stay here? But in a corporate environment, explaining Haskell as “algebraic functional programming” might avoid the notion of purity and (implicitly) impracticality, as well as provide an opportunity to explain Haskell’s IO monad in terms of its benefits in program design.

The point isn’t to abandon the effective “Avoid $ SuccessAtAllCosts” philosophy, because that’s a philosophy of the GHC Committee. The language Haskell will remain Haskell, not compromising simply to seek adoption. But the branding of Haskell might be improvable.

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [July 28, 2022, 9:39am UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/2 "2022-07-28T09:39:31Z")

</div>

See also: [Conal Elliott » The C language is purely functional](http://conal.net/blog/posts/the-c-language-is-purely-functional)

Although, I’ll admit that I am not completely sure what the conclusion of that blog post is. Is Conal Elliot saying we should actually call C a pure language, or that we should call Haskell impure, or that we should keep the status quo because the alternatives are absurd?

Personally, I think I’d prefer keeping the status quo. Calling C pure or calling Haskell impure would make the word “pure” lose all its meaning (outside of tiny experimental programming languages).

Of course _marketing_ the language as pure doesn’t make that much sense, because newcomers are probably not aware of the implications of purity. Instead we should focus on those implications, like making code easier to reason about in isolation and ease of refactoring.

---

<div class="post-metadata">

**Author:** ![f-a](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/f-a/32/2740_2.png) [@f-a](https://discourse.haskell.org/u/f-a)\
**Post date:** [July 28, 2022, 9:48am UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/3 "2022-07-28T09:48:49Z")

</div>

> [@Liamzy](#):
>
> It has support for procedural-looking code (do notation)

procedural-looking, but not procedural.

Back on topic: I suspect we need less propaganda, and more useful programs written in Haskell, like git-annex, hledger and friends.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [July 28, 2022, 10:19am UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/4 "2022-07-28T10:19:30Z")

</div>

Haskell isn’t singular - there’s Clean and Miranda(R) and more recently _R_: I’m now wondering if any of them are also contemplating a changing of their _“marketing”_ nomenclature.

Back in 1987, Haskell was relatively easily to recognise as being pure ([embarrassingly so](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9725&rep=rep1&type=pdf), apparently) - that was then, this is now and Haskell has evolved (yes, acquiring some features known to cause disagreement). The Haskell community is largely interested in _programming_, not _marketing_ so the _“front-page”_ description hasn’t changed much, if at all.

Yes, the use of the term _“pure”_ (apart from being rather pejorative) does over-extend the dictionary definition somewhat, but so far no more descriptive term has so far appeared. As for _“algebraic”_…that _could_ scare off potential new Haskellers more than _“pure”_ ever did.

Haskell is unique in many ways and has acquired the greatest _“mind’s share”_ of research and development in this space, so it will obviously be "_first with features"_ (and problems) - that the description hasn’t kept up isn’t that much of a surprise.

> [@f-a](#):
>
> Back on topic: I suspect we need less [diversions], and more useful programs written in Haskell, like `git-annex`, `hledger` and friends.

…who knows: maybe a better description for Haskell might be found in that process.

---

<div class="post-metadata">

**Author:** ![Abab9579](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/abab9579/32/2163_2.png) [@Abab9579](https://discourse.haskell.org/u/Abab9579)\
**Post date:** [July 28, 2022, 1:03pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/5 "2022-07-28T13:03:19Z")

</div>

I have always found it uneasy to face/state the term “pure”. It gives off this… strange… sense of medieval wicked notion of morale. Why should we call it “Pure FP” when simply “FP” would suffice? Could say “Typed FP” or even “Rigorous (Typed) FP” if one wants to further the accuracy.

Oh. By the way, we have laziness. Which comes with another comparable negative connotation. I do not know how to feel about this one, though. Many dislike inherent laziness of haskell, after all…

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [July 28, 2022, 1:11pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/6 "2022-07-28T13:11:18Z")

</div>

> [@Abab9579](#):
>
> Why should we call it “Pure FP” when simply “FP” would suffice?

Most FP languages don’t enforce purity: Scala, F#, OCaml, Clojure, etc.

---

<div class="post-metadata">

**Author:** ![Abab9579](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/abab9579/32/2163_2.png) [@Abab9579](https://discourse.haskell.org/u/Abab9579)\
**Post date:** [July 28, 2022, 1:16pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/7 "2022-07-28T13:16:12Z")

</div>

Do we need this distinction for common nomenclature, though? I personally find such distinction needlessly discriminating if used often.

Btw, Is the notion “Rigorous FP” bad?

---

<div class="post-metadata">

**Author:** ![rae](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/rae/32/888_2.png) [@rae](https://discourse.haskell.org/u/rae)\
**Post date:** [July 28, 2022, 1:32pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/8 "2022-07-28T13:32:23Z")

</div>

But Haskell _is_ pure: When you say something like

```haskell
recipe :: FilePath -> IO String
recipe path = do
  ... getDirectory ...
  ... readFile ...
  ... other stuff ...

```

calling `recipe` doesn’t actually _do_ anything. Instead, `recipe` returns an `IO` action, to be executed at a later time – a recipe. Accordingly, evaluating `main` does a whole lot of _pure_ work, building up an elaborate recipe for what would happen at runtime, but evaluating `main` doesn’t actually execute this recipe. The Haskell runtime will, after evaluating `main`, then actually perform the actions specified there.

So I think calling Haskell pure is technically accurate and would argue against shying away from this – it’s (for me) the chief quality that makes Haskell awesome.

On the other hand, as raised in this thread, I too have sometimes been uncomfortable with the choice of the word “pure” for the concept of side-effect-free. “pure” has too many moralistic connotations. But I think that ship has sailed, given that this word has this meaning quite widely. (For example, the Java API documentation describes some stream operations as working only on pure function objects.)

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 28, 2022, 1:46pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/9 "2022-07-28T13:46:38Z")

</div>

> calling `recipe` doesn’t actually _do_ anything

Can you state formally what that means?

> evaluating `main` does a whole lot of _pure_ work, building up an elaborate recipe for what would happen at runtime, but evaluating `main` doesn’t actually execute this recipe. The Haskell runtime will, after evaluating `main`, then actually perform the actions specified there.

Could you describe in more detail how to apply this to

```haskell
recipe :: FilePath -> IO String
recipe path = do
   b <- someCondition path
   if b then someFunction path else pure ""

main :: IO ()
main = recipe someFilePath

```

For example, what does evaluating `main` entail? Presumably it doesn’t involve performing the actions of the `someCondition` “subrecipe” (since that would not be pure) and therefore “evaluating `recipe`” can’t be “building up an elaborate recipe” for `someFunction`. In this case the following must happen in this order:

- build up recipe for `someCondition`
- actually perform the actions for `someCondition`
- build up recipe for `someFunction`
- actually perform the actions for `someFunction`

I can only conclude that “building up an elaborate recipe” and “actually performing the actions specified there” must be tightly intertwined, so they are not two distinct stages! Do you agree?

---

<div class="post-metadata">

**Author:** ![rae](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/rae/32/888_2.png) [@rae](https://discourse.haskell.org/u/rae)\
**Post date:** [July 28, 2022, 2:50pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/10 "2022-07-28T14:50:46Z")

</div>

> [@tomjaguarpaw](#):
>
> Can you state formally what that means?

Yes: evaluating `recipe x` (for any `x`) to WHNF causes no side effects.

> [@tomjaguarpaw](#):
>
> For example, what does evaluating `main` entail?

```haskell
main =
recipe someFilePath =
someCondition someFilePath >>= \b -> if b then someFunction someFilePath else pure "" =
bindIO (someCondition someFilePath) (\b -> if b then someFunction someFilePath else pure "") =
IO (\ s -> case (unIO (someCondition someFilePath)) s of (# new_s, a #) -> unIO ((\b -> if b then someFunction someFilePath else pure "") a) new_s)

```

which is a value. This value can be passed around, duplicated, evaluated redundantly again, etc., with no side effects, at all, occurring. It’s only when the function contained in the value is called – which requires a `State# RealWorld` – that any side effects happen, but this is beyond the bounds of normal Haskell code. (You can, of course, fake a `State# RealWorld` and get Haskell to behave non-purely, but you can also do that with `unsafePerformIO`. I’ve implicitly assumed that we’re avoiding such tricks.)

I see what you’re getting at with “intertwined”, but I don’t find it all that helpful: all I’m saying is that evaluating `recipe` (or `main` even) is a pure operation that causes no side effects.

---

<div class="post-metadata">

**Author:** ![gilmi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/gilmi/32/45_2.png) [@gilmi](https://discourse.haskell.org/u/gilmi)\
**Post date:** [July 28, 2022, 2:56pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/11 "2022-07-28T14:56:13Z")

</div>

I like to talk about referential transparency more than pure/impure. In Haskell writing `x = y` means that x and y are interchangeable. That’s not true for most other languages. For example in C:

```haskell
#include <stdio.h>

int increment(int x) {
    printf("value was %d\n", x);
    return x + 1;
}

```

```haskell
int main(void) {
    int x = 1;
    printf("y is: %d\n", increment(x));
    return increment(x);
}

```

```haskell
int main(void) {
    int x = 1;
    int y = increment(x);
    printf("y is: %d\n", y);
    return y;
}

```

The two `main` functions do not behave the same way and that’s unfortunate. Haskell will always let you do this kind of transformation fearlessly and the behaviour will stay the same.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 28, 2022, 2:57pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/12 "2022-07-28T14:57:21Z")

</div>

> [@rae](#):
>
> > [@tomjaguarpaw](#):
> >
> > Can you state formally what that means?
> 
> Yes: evaluating `recipe x` (for any `x`) to WHNF causes no side effects.

That’s just replacing one undefined (in this discussion) concept with another! What does it mean to “cause no side effects”?

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 28, 2022, 2:57pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/13 "2022-07-28T14:57:56Z")

</div>

> [@gilmi](#):
>
> I like to talk about referential transparency more than pure/impure.

Yes! This is where I am hoping my dialogue with Richard will lead …

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 28, 2022, 3:01pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/14 "2022-07-28T15:01:15Z")

</div>

(And given that you appealed to “the Java API documentation describes some stream operations as working only on pure function objects”, a definition of purity in terms of WHNF or `RealWord#` seems insufficiently general.)

---

<div class="post-metadata">

**Author:** ![rae](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/rae/32/888_2.png) [@rae](https://discourse.haskell.org/u/rae)\
**Post date:** [July 28, 2022, 3:19pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/15 "2022-07-28T15:19:25Z")

</div>

Every system has to define its own meaning of “side effect”. For example, is the heating up of a processor a side effect? What about consumption of finite memory? We usually say “no”. I don’t feel able to give a complete list of side effects, but it includes things like I/O and reading the time of day. I’m not really sure how to do better here, without writing down a full formal specification of an operating computer (including e.g. the temperature of components) and then an equivalence relation on that specification, where a pure computation leaves the computer in a state equivalent to the one it was in previously.

---

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [July 28, 2022, 3:23pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/16 "2022-07-28T15:23:15Z")

</div>

The problem is, Haskell implicitly has support for multi-paradigm programming via both do notation, object libraries, and even logic programming via monads. Pure in the sense that the core language is functional, and that multi-paradigm programming is done through a functional programming layer, creates some level of confusion, and makes Haskell not seem “pragmatic”, when it is very pragmatic, it just avoids compromising by providing first-class support for multi-paradigm programming and resorts to different hacks to preserve its non-strict and functional-first nature.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 28, 2022, 3:32pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/18 "2022-07-28T15:32:30Z")

</div>

There are a couple of sides to the issue

1. The technical definition of “pure”. That’s what Richard, gilmi and I have been discussing.
2. Regardless of the technical definition, the impression it gives to the outside world. I think this is the main thrust of your original post, William.

I agree with you, William. In so many online discussions in general programming fora I see comments of the following sort:

> Haskell is a pure language, that means it can’t have state or side effects, but modifying state and causing side effects are essential in a real-world system, therefore Haskell is useless in the real world.

My mind always boggled how such commenters could believe what they are saying. Do massive corporations like Facebook and Standard Chartered really use Haskell despite it being useless in the real world?! But the point remains: people do seem to think this.

I’m with gilmi and (I think, you): not only does “pure” (in the programming language sense, let alone the moral sense) give the wrong connotations, _it’s not even what we value at all_! We value referential transparency. The notion of “purity” is a poorly-defined approximation to referential transparency.

Here’s a challenge to folks who like the notion that “Haskell is a pure language”: please explain what benefit you get from Haskell’s “purity” that is not also a benefit of Haskell’s referential transparency.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [July 28, 2022, 3:37pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/19 "2022-07-28T15:37:56Z")

</div>

@tomjaguarpaw, is the following URL yours?

[http://h2.jaguarpaw.co.uk/posts/impure-lazy-language](http://h2.jaguarpaw.co.uk/posts/impure-lazy-language)

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [July 28, 2022, 3:39pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/20 "2022-07-28T15:39:26Z")

</div>

Yes!!!

[Exclamation marks added because Discourse requires that posts must be at least 20 characters]

[EDIT: intriguingly, although I wrote 17 exclamation marks, Discourse only shows 3]

---

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [July 28, 2022, 3:50pm UTC](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850/21 "2022-07-28T15:50:58Z")

</div>

> [@tomjaguarpaw](#):
>
> I’m with gilmi and (I think, you): not only does “pure” (in the programming language sense, let alone the moral sense) give the wrong connotations, _it’s not even what we value at all_! We value referential transparency. The notion of “purity” is a poorly-defined approximation to referential transparency.

Honestly, I think we could save pure by saying that Haskell is a language with “purely functional semantics”, then pick some kind of marketing buzzword to refer to referential transparency or a pure-impure separation. Purely functional semantics → is what Haskell actually is, since do notation etc is just syntax that converts down to functional code.

The idea is, for people who understand what purity means, purely functional semantics, or a similar term, is equivalent to purity, whereas for bean-counters / language warriors, they have no bleeding clue what it means. It’s a dog-whistle, except for academics instead of reprobates.

So what we’d do would be to describe Haskell as a \_\_\_ language, with purely functional semantics, a very strong type system, and non-strict evaluation.

On the top level, then, we find some other term to describe Haskell, its benefits, and utility. Because, after all, the language designers were busier working on the language design than the marketing (see: “Cute, fuzzy things”). But that’s what Haskell Foundation is for, right? HF handles the business and marketing side, GHC Committee handles the language itself.

===

Yeah, and I’m skirting the issue. Referential transparency is a good academic term, but a bad marketing term. If you were Sun, preparing to blow hundreds of millions on Java’s marketing budget, and were all of a sudden forced to blow hundreds of millions on Haskell’s marketing budget, how would you describe Haskell?

[Next page](https://discourse.haskell.org/t/should-haskell-be-rebranded-away-from-pure-functional-programming/4850.md?page=2)