Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarify wording on pure-functions overview to allow immutable hidden state, and add an example #3134

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 18 additions & 3 deletions _overviews/scala3-book/fp-pure-functions.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Another feature that Scala offers to help you write functional code is the abili
A _pure function_ can be defined like this:

- A function `f` is pure if, given the same input `x`, it always returns the same output `f(x)`
- The function’s output depends _only_ on its input variables and its implementation
- The function’s output depends _only_ on its input variables and its implementation (and in case of a closure, any immutable data that it captures)
- It only computes the output and does not modify the world around it

This implies:
Expand Down Expand Up @@ -57,7 +57,7 @@ Conversely, the following functions are _impure_ because they violate the defini

Impure functions often do one or more of these things:

- Read from hidden state, i.e., they access variables and data not explicitly passed into the function as input parameters
- Read from hidden mutable state, i.e., they access non-constant data that was not explicitly passed into the function as input parameters
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"non-constant" is not really a synonym for "mutable". I would suggest using the word "mutable" again even if it feels a bit repetitive; it's more important to be precise.

- Write to hidden state
- Mutate the parameters they’re given, or mutate hidden variables, such as fields in their containing class
- Perform some sort of I/O with the outside world
Expand Down Expand Up @@ -98,6 +98,21 @@ def double(i: Int): Int = i * 2

{% endtabs %}

The next example is bit more tricky. Here, `i` is not passed as a parameter, but instead referenced directly from the outside.
This works in Scala because functions act as closures - they can capture the state around them. As long as that state is *immutable*, such a closure is still considered pure.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this is the best wording since we usually use "state" to talk about mutable state. Not all of the time. I would suggest "capture values from enclosing scopes".

In this case, the function always returns `6` and each call can be safely replaced with its result.

{% tabs fp-pure-function-closure %}

{% tab 'Scala 2 and 3' %}
```scala
val i = 3
def double(): Int = i * 2
```
{% endtab %}

{% endtabs %}

If you’re comfortable with recursion, here’s a pure function that calculates the sum of a list of integers:

{% tabs fp-pure-recursive-function class=tabs-scala-version %}
Expand Down Expand Up @@ -129,7 +144,7 @@ If you understand that code, you’ll see that it meets the pure function defini

The first key point of this section is the definition of a pure function:

> A _pure function_ is a function that depends only on its declared inputs and its implementation to produce its output.
> A _pure function_ is a function that depends only on its declared inputs, captured constants, and its implementation to produce its output.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggest "closed-over values" rather than "captured constants"

> It only computes its output and does not depend on or modify the outside world.

A second key point is that every real-world application interacts with the outside world.
Expand Down