undefined | Better HN

0 pointselbear2y ago0 comments

So, another definition of a pure function is that, for a particular input it will always return the same output.

Your example respects the rule:

    f({x=1}) == 1
    f({x=2}) == 2

But it's true that the two rules I gave are not enough to make a function pure. Because I didn't say anything about I/O. So, a function that follows the rules about inputs and outputs, could still do I/O and change its outputs based on that.

Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming language..."

The other benefit is that such a language forces you to be explicit about I/O. It does it in such a way that even functions that do I/O are pure. The good part is that, if you use it long enough, it can teach you the discipline to be explicit about I/O and you can use this discipline in other languages.

For example, this is how I see this principles being used in Python:

https://elbear.com/functional-programming-principles-you-can...

0 comments

4 comments · 1 top-level

Dylan168072y ago· 3 in thread

> Your example respects the rule:

Every definition of purity I can find that talks about objects/references says that if you pass in the same object/reference with different contents then that's not pure.

Your version differs from mine on that aspect. It passes two unrelated objects.

> Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming language..."

I interpret saying a language is "purely functional" as being more about whether you're allowed to write anything that isn't functional. I can talk about BASIC being a "purely iterative" language or about "pure assembly" programs, without any implication of chunks of code being pure.

elbearOP2y ago

I gave it some more thought.

I now believe that learning a language like Haskell (or Elm or PureScript) forces you to see your program as pipes that you fuse together.

It's not just functions. Haskell has only expressions and declarations. That means, for example, that you are forced to provide an `else`, when you use `if`. The idea is that you have to keep the data flowing. If a function doesn't provide a meaningful value (so it returns nil, None), you have to handle that explicitly.

And, btw

> Your version differs from mine on that aspect. It passes two unrelated objects.

Those two objects are not unrelated. They have the exact same structure (an attribute named "x"). So they could be considered two values of the same type.

Dylan168072y ago

I mean that the identity is unrelated. Yes, you can say they're the same type. But I'm actually passing the same object in. If f evaluated lazily, it could return 2 from both calls. Something like:

  define f(o): return o.x
  let a = {x=1}
  n = f(a) // n is not evaluated yet
  a.x = 2
  m = f(a)
  return n + m // returns 4

1 more reply

simiones2y ago

Purely functional language is pretty universally taken to mean that the language enforces function purity for all functions [perhaps with some minor escape hatches like Haskell's unsafePerformIO].

j / k navigate · click thread line to collapse