[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Re: Arch Cache & cached archives
Date: Wed, 15 Sep 2004 21:36:24 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

Tom Lord wrote:

You are trying to say that:


        memoizing is what you do with referentially transparent

        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.


        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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]