Hacker News Reader

Comment by Veedrac | Hacker News Reader

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

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.)

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?

Reply on news.ycombinator.com