[Top][All Lists]
[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
- [Fenfire-dev] PEG: functional futureproof api, Tuomas Lukka, 2003/09/05
- Re: [Fenfire-dev] PEG: functional futureproof api, Benja Fallenstein, 2003/09/07
- [Fenfire-dev] Repost: Functional PEG, Tuomas Lukka, 2003/09/07
- [Fenfire-dev] Re: Repost: Functional PEG, Benja Fallenstein, 2003/09/08
- [Fenfire-dev] Repost 2: Functional PEG, Tuomas Lukka, 2003/09/08
- [Fenfire-dev] Re: Repost 2: Functional PEG, Benja Fallenstein, 2003/09/08
- [Fenfire-dev] Re: Repost 2: Functional PEG, Tuomas Lukka, 2003/09/08
- [Fenfire-dev] Re: Repost 2: Functional PEG, Benja Fallenstein, 2003/09/08
- [Fenfire-dev] Re: Repost 2: Functional PEG,
Tuomas Lukka <=
- Re: [Fenfire-dev] Repost: Functional PEG, Hermanni Hyytiala, 2003/09/08
- Re: [Fenfire-dev] Repost: Functional PEG, Tuomas Lukka, 2003/09/08
- Re: [Fenfire-dev] Repost: Functional PEG, Hermanni Hyytiala, 2003/09/08
- Re: [Fenfire-dev] Repost: Functional PEG, Tuomas Lukka, 2003/09/08
Re: [Fenfire-dev] PEG: functional futureproof api, Tuomas Lukka, 2003/09/07