Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
epic-64 wants to merge2 commits intoscala:main
base:main
Choose a base branch
Loading
fromepic-64:clarify-purity-in-closures

Conversation

@epic-64
Copy link

@epic-64epic-64 commentedDec 21, 2024
edited
Loading

Updates the "pure functions" overview athttps://docs.scala-lang.org/scala3/book/fp-pure-functions.html

  • adds clarification that accessingimmutable hidden state is still considered pure
  • adds an example of this in form of a closure

@epic-64
Copy link
Author

epic-64 commentedDec 21, 2024
edited
Loading

there are still some typos, sorry, marking it as draft until they are fixed

@epic-64epic-64 reopened thisDec 21, 2024
@epic-64epic-64 marked this pull request as draftDecember 21, 2024 17:57
@epic-64epic-64 marked this pull request as ready for reviewDecember 21, 2024 18:04
Impure functions often do one or more of these things:

- Read from hidden state, i.e., they accessvariables anddata not explicitly passed into the function as input parameters
- Read from hiddenmutablestate, i.e., they accessnon-constantdata 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.

epic-64 reacted with thumbs up emoji
{% 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".

epic-64 reacted with thumbs up emoji
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"

epic-64 reacted with thumbs up emoji
@epic-64epic-64 marked this pull request as draftJanuary 4, 2025 02:05
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@SethTisueSethTisueSethTisue left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@epic-64@SethTisue

[8]ページ先頭

©2009-2025 Movatter.jp