Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Where does the name of the `pure` function in the `Applicative` type class come from?
At this point in my learning journey, I simply accepted that this function is called pure (both in Haskell and in PureScript), but it would have helped a lot if I had known the reasoning behind this name.
Both the Haskell reference and the PureScript docs use the word "lift",
Haskell Lift a value into the Structure.
PureScript
purecan be seen as the function which lifts functions of zero arguments
but lift is already in use (e.g., for monad transformersHaskell, Purescript).
The PureScript reference for pure also uses the word "wrap", but I understand now why the functor explanations along the lines of "wrap value in a box" can be misleading or miss the point entirely. For these reasons, I do like the name pure as it has no "baggage" and I can focus on understanding the topic without preconceptions.
Books and tutorials using the word "context" helped me understand the more abstract constructs, so I sometimes wondered if using "embed" would make sense here, but then I let it go.
Anyway, I still research from time to time to figure out pure's etymology, but did not get any closer yet.
1 answer
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| toraritte | (no comment) | Jun 3, 2024 at 10:00 |
A direct answer to your question of where the name comes from is the paper that introduced Applicative functors, Applicative programming with effects (PDF). Quoting from there:
The idea is that
pureembeds pure computations into the pure fragment of an effectful world[.]
I would say this is indeed the intuition many Haskell (and presumably PureScript) programmers have for it.
The intuition is that a type like F a for a monad or applicative functor F models a computation that may have effects. pure x then models the "effectful computation" that happens to have no effects and returns x, i.e. is pure in the sense of "pure functional programming". The "lifting" intuition should also be reasonably clear here. We're "lifting" "pure" computations into the world of effectful computations.
0 comment threads
0 comment threads