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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add memoize #1138

Closed
vicrac opened this issue Feb 15, 2020 · 6 comments
Closed

Add memoize #1138

vicrac opened this issue Feb 15, 2020 · 6 comments

Comments

@vicrac
Copy link
Contributor

vicrac commented Feb 15, 2020

馃殌 Feature request

Add helper for memoization:

const f = arg => {
    console.log("some costly computations")
    return result
}

const memoized = memoize(f)

// logs "Some costly computation"
memoized(1)

// logs "Some costly computation"
memoized(2)

// Cache hit, element returned without computation
memoized(1)

Desired Behavior

It would be nice if memoization was included in fp-ts. It's such a fundamental concept in functional programming I nearly regret it's not shipped with the language itself ;) I would also appreciate fp-ts being self-contained, battery included package for functional programming, without need to install Ramda/lodash or writing own helpers for such a basic feature.

Suggested Solution

If this is approved, I can open a PR on that

Who does this impact? Who is this for?

All users of pure but costly functions ;)

Your environment

Software Version(s)
fp-ts 2.4
TypeScript 3.7.3
@raveclassic
Copy link
Collaborator

Again - what bounds do we define for fp-ts to include such helpers? IMO this is definitely smth for an external library.

@vicrac
Copy link
Contributor Author

vicrac commented Feb 16, 2020

@raveclassic I agree - a consistent guide/standard for placing new features/shaping API is very desirable.

On the other hand, I am pretty sure memoization should live in the very core of any functional library - as I said, I would welcome including it in the language itself ;) (yeah, it's not gonna happen, but imagine e.g. pure function f(n: number) { ... } - of course it has its own limitations, but still... ;))

@raveclassic
Copy link
Collaborator

raveclassic commented Feb 16, 2020

When we introduce memoization we should always think of the following questions:

  • what is the size of our cache?
  • if cache is infinite, then how do we deal with non-primitive arguments? how do we create the key? Do we have any way to clear the memory?
  • if cache is finite then what is its size, 1-level or greater?
  • what is the underlying implementation of the cache? Is it possible to reuse an existing library that's already in the project?
  • and in the end - should we memoize the core itself?

All these question are too specific for such an abstract library like fp-ts.

@vicrac
Copy link
Contributor Author

vicrac commented Feb 16, 2020

@raveclassic Fair point, let's see what @gcanti thinks about it.

Just for transparency, I usually implement cache as simple Map (which allows using any values as keys, including objects) with limited size (and invalidating oldest elements). I limit memoization to single-argument functions for simplicity.

@gkamperis
Copy link

Personally I see fp-ts as a lib that implements the theories (category, abstract algebra, etc). with some common usage implementations.

Caching is a huge subject onto its own - notoriously difficult.
memoization is a practical consequence of functional purity.

Personally I see little reason why it should be tied into fp-ts itself.

Another example would be immutability.
It would be great if we can also get it baked in but it is not a FP concern.

So maybe an ecosystem lib that provides this functionality as a configurable opt-in (like @ngrx does re immutability) would be the best solution.

@gcanti
Copy link
Owner

gcanti commented Feb 17, 2020

Ideally an (fp-ts) API should have a single, obvious implementation.
Otherwise, i.e. if we must make an opinionated choice, it would be better a dedicated library.

@vicrac vicrac closed this as completed Feb 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants