Re: [Gnu-arch-users] Re: Arch Cache & cached archives

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    [what is memoizing vs. caching]

    > Roughly speaking, when you have a function or process that is costly to 
    > perform, and will likely be repeated, you can speed things up by storing 
    > the answer, and using that answer instead of repeating the process. 
    > This only works if the answer will always be the same for the same 
    > inputs, and usually requires a set of answers to be stored, indexed by 
    > the inputs that produced them.

    > With caching, in contrast, you are storing answers that may change. 
    > Caches usually have built-in expiration mechanisms, and ways to check 
    > whether the cached data is out of date.

I suppose that there is no official source for definitions but that
isn't a very good one, imo.

You are trying to say that:

    WRONG ANSWER:

        memoizing is what you do with referentially transparent
        functions

        caching is what you do with functions which are not
        referentially transparent


In fact, non ref-trans functions can (seemingly always) be converted
to ref-trans functions with the addition of extra parameters.  Thus,
both kinds of function can be both memoized and cached.

    RIGHT ANSWER:

        memos never forget (of their own accord, anyway)

        caches do


    > So we can store a tarred, gzipped tree of a revision
    > permanently.  But the information about which cacherevs a mirror
    > contains is subject to change without notice.

Which shouldn't much matter to a client.  The cacherev is a
well-defined fixed entity regardless of whether or not a mirror has it
cached.  Clients should care only about the cheapest way to compute
this or that higher-level function where cacherevs may or may not be
used in that computation.

E.g., clients shouldn't care whether the cacherev they get to use came
from an archive or was computed locally.   If it's handy it's handy
and that's that.

-t