Re: [Fenfire-dev] PEG: functional futureproof api

[Benja Fallenstein]

Tuomas Lukka wrote:
> Functions and caching are here to stay with us. 
> However, the caching is currently pretty nasty for the programmer
> and requires active thinking, especially in the case of super-lazy
> functions.

Say what super-lazy functions are before referencing them.

> The biggest API change is not an API change *per se* but a semantic change.
> So far, ``PureFunction`` and ``PureNodeFunction`` have been required to 
> be pure, interface-wise, i.e. their f() *method* may not return values
> depending on anything other than the parameter.
>
> To make handling functions convenient, we shall relax this requirement:
> a ``PureFunction`` must be pure **iff** all its constructor parameters
> that implement ``Function`` are pure, and likewise for ``PureNodeFunction``s.

I'm not sure that having ``PureFunction`` as a separate interface makes 
much sense, then, since there is no type-safety. (A ``PureFunction`` may 
or may not be pure, you don't know.)

> Any object implementing a ``Function`` interface (except for the special 
> Functional
> API classes) shall not leak memory or cause crashes or improper results if any 
> of
> its constructor parameters that implement the ``Function`` API throw an 
> ``Error``.
> The error must pass through the ``Function`` invocation to the caller.

Huh?

*Anything* that calls Java code must not leak memory or cause crashes or 
improper results if the Java code throws an exception. It must handle 
the exception or bubble it.

> This allows us to emulate some sort of continuation mechanism for Java.

I don't think it's very close to continuations, which are a *very* 
general-purpose tool. (You could say that it's one thing you can do with 
continuations, but so are for-loops.)

> Creating functions
> ------------------
>
> Functions shall no more be created directly (it's allowed but will not be cacheable 
> &c).
> Instead, a reflective Function creation API shall be used:

This needs a LOT more explanation! Explain how the API works, instead of 
just giving the javadoc. What are the ideas and concepts behind it?

>     interface Functional {
>         /** Hints about a Function class.
>          * Created using HintsMaker.
>          * An empty interface in order to be unmodifiable.
>          */

E.g. this is completely incomprehensible to me; it doesn't relate to 
anything you said before.

> Example about using the API

"Example about?"

> First, define two functions::
>
>     public class G implements PureFunction {

It would help understanding if the functions in the example had 
real-world meaning, instead of being "F" and "G."

> And construction the functions::
>
>     Functional.Node node1 = Functional.createNode(
>         "N1",
> 	G.class, 
> 	new Object[] {"X"});
>     Functional.Node node2 = Functional.createNode(
>         "N2",
>         F.class,
>         new Object[] {"Y", node1});
>
> This constructor is "equivalent" to::
>
>     Function node1 = new G("X");
>     Function node2 = new F("X", node1);
>
> except that the result may be cached.

It certainly *looks* complex. You should really discuss the model first 
if you want to justify this ;-)

- Benja