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

[Aaron Bentley]

Tom Lord wrote:

> 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

I meant to say that you can cache both referentially-transparent and 
non-referentially transparent functions, but I was sloppy.

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

Perhaps theoretically, but there are some practical limitations.  The 
extra parameters you require may not be cost-effective to produce.  For 
example, to memoize "tla revisions" on an http archive, you'd need to 
check whether the .listing file had been updated.  That check has the 
same latency as retrieving the .listing file, so with common numbers of 
revisions, it's not cost-effective.

And some parameters are not available without changing the system.  The 
pfs interface doesn't provide a way to check whether the .listing file 
has been updated without downloading it.  The size of the .listing file 
is also unavailable.

So the behavior of non-referentially-transparent functions is worth 
considering separately, even if they theoretically could be made 
referentially transparent.

>     RIGHT ANSWER:
>
>         memos never forget (of their own accord, anyway)
>
>         caches do

While that's a true distinction, I think "it's unsafe to memoize a 
non-referentially transparent function" is an important statement to make.

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

The client needs that information to build a revision efficiently.  It 
needs it to perform the cachedrevs command.

Aaron