Hacker News Reader

Comment by millstone | Hacker News Reader

No, the example is unmotivated, but not unreasonable.

For example, say the two functions are computationally expensive, and you want to make them faster. The "piece of state" is a shared cache, i.e. memoization. Furthermore, there's reason to believe that if function A is called with value X, then function B will not be called with Y anytime soon. So if A(X) is called, Y(B) ought to be evicted from the cache.

This is awkward to implement in pure functional languages, but it's not a terrible idea. You can still reason about the functions, test them in isolation, etc.

View on HN

Your example is very different. It seems you're still describing a pure API: testing those new function implementations can be done with the same test suite used for the slower variants.

In the blog post the author choose to specify that the observable behaviour is not pure.

What if the cache involves IO? The behaviour is then assuredly not pure.

What sort of a cache would use IO? Not any cache I've heard of. (Genuinely interested)

A cache too big to fit in memory

Any cache that is provided by an external process, or even by a remote machine, such as memcached.

I guess I should clarify and say "What sort of a cache would use IO and make a pure function impure?". Even if the cache is so large that it doesn't fit in memory, its behaviour would still be referentially transparent.

That's only if you don't count the IO itself as a side-effect.

Does a language like Haskell give you the choice? If so,would it be idiomatic?

One you want to keep around between invocations of the program?

When you do this, the type system should reflect the fact that function has changed it's signature from `A => B` to `A => MaybeDoesntReturnOrHasLatency[B]`. Then the compiler will force downstream clients to take this into account, preventing weird hard to debug errors later on.

FWIW, I'm not arguing about should or shouldn't - I'm just strengthening the original argument.

That said, I don't think small bounded latency is a good thing to encode in a typesystem, much as I don't think runtimes should be encoded in a typesystem. It gives too much inflexibility for too little gain.

I have wanted small bounded latency to be encoded before. (I'd also want the ability to ignore that information in most other programs I worked on. With the right sort of type system, you don't have inflexibility.)

Did he? The author specified that the function "behaves differently;" to my reading this doesn't require that it be impure. A memoized function behaves differently than the underlying function (with observable consequences, like performance), but still obeys referential transparency, etc.

That's easy to implement in Haskell using unsafePerformIO and it's only "unsafe" in the sense that normal code in a non-purely functional language is unsafe. It's only awkward if the impure behavior is observable.

Right, and that nicely illustrates the point. This is easy to implement in Haskell to the extent that Haskell is not purely functional.

Would passing around a "state" variable that included this cache be sufficient, or does one really need to implement a global variable?

Reply on news.ycombinator.com