fenfire-dev
[Top][All Lists]
Advanced

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

[Fenfire-dev] Re: Repost 2: Functional PEG


From: Tuomas Lukka
Subject: [Fenfire-dev] Re: Repost 2: Functional PEG
Date: Mon, 8 Sep 2003 12:03:08 +0300
User-agent: Mutt/1.5.4i

On Mon, Sep 08, 2003 at 11:56:52AM +0300, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> >On Mon, Sep 08, 2003 at 11:25:51AM +0300, Benja Fallenstein wrote:
> >>I don't understand FunctionInstance-- an instance of the class 
> >>FunctionInstance represents an instance of a class implementing Function 
> >>or NodeFunction? What's the point here? Why not use Function itself?
> >
> >Because it is relevant for the Functional API instances to know for
> >which FunctionInstances the actual values of the function are required
> >from outside.
> 
> What does "the actual values of the function are required from outside" 
> *mean*?
> 
> How does FunctionInstance tell this? It has only one method, which 
> returns the Function.

Ok, say I construct a function as

        f(g(x))

I may be able to cache better if I know that values of g(x) are not required
anywhere else but for f(g(x)).

The API knows this because getCallableFunction was called only for f, not for g.

> >>I still don't understand what hints are. I also don't know what a 
> >>Functional is (it has no javadoc?!?).
> >
> >Fixed
> 
> Not the part about not explaining what hints are.

In the javadoc.

> **Please**, explain the *model* first, before giving the interface.

The model of the function DAG or the model of how the caches would work?

> >>I think that the "Creating functions" section may be the place to expand 
> >>on how the whole thing works.
> >
> >Works? The problem is that this PEG is not about *how* it will work, but
> >about the interface that can remain stable w.r.t. how it works.
> 
> You need to say--
> 
> - what the model is (the model that is expressed by the API classes)
> - how that model is expected to be used
> 
> You cannot create an interface that can remain stable if you have *no* 
> idea how the information communicated through this interface will be 
> used. You need to explain what information is supposed to be conveyed 
> through your API, and why this information is deemed useful for caching 
> &c. You obviously have something in mind, but you don't explain it.

I'm a bit stumped by this - I don't know how or what to start explaining. Could 
you come
on IRC? I think that could help.

> I think I understand what a "functional DAG" is. However, for 
> evaluation, it works just fine if every function knows the other 
> functions it needs to call; there is no additional information that 
> needs to be saved, and it is not necessary to access this information 
> from the outside. You assert that this is important for caching and 
> super-lazy functions-- **but you never say why!**
> 
> The closest thing is that you say that "the caches need to co-operate," 
> but you do not say *how*.

The introduction has an example:

        As an important example of why this API is needed, consider the 
NodeFunctions in FenPDF
        that provide the Canvas2D with the Placeables for each node.
        The functions could be written as ::

            f(x) = Multiplex( Wrap( PageNodeFunc(x), 1 ), TextNodeFunc(x) )
            g(x) = Multiplex( Wrap( PageNodeFunc(x), 2 ), TextNodeFunc(x) )

        The problem is that we want to

        1) Cache the result of f(x) and g(x) normally

        2) Cache the result of PageNodeFunc(x) super-lazily as it is slower to 
run.

        We do *not* want to cache TextNodeFunc super-lazily, since it is quite 
fast to run.
        However, to allow the last-used nodes to be calculated first, we want 
to use a LIFO
        (last-in-first-out) computation for the nodes. However, if the 
placeholder
        from the super-lazily cached PageNodeFunc is retrieved from the cache 
of the Multiplex
        function, the super-lazy cache's last-used date will remain wrong.

        Therefore, it is obvious that the caches need to co-operate. This API 
allows
        a single class to take care of all caches, so this co-operation could 
be arranged.

What is unclear about this?

        Tuomas




reply via email to

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