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

[Tuomas Lukka]

Thank you for the comments - I didn't realize how unclear I was being.
It's good that you're here, keeping me in check.

Reposting the PEG in a few minutes.


On Sun, Sep 07, 2003 at 06:55:08PM +0300, Benja Fallenstein wrote:
> 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.

Fixed

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

The point is that the PureFunction object itself needs to identify itself
as pure to the Functional API somehow.

Otherwise, the Functional API can't cache things.

Using a hint would be possible - would you prefer that?

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

Yes. This is just making it especially sure here.

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

Fixed.

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

Yes, I now realize how obtuse my explanations were. Fixing.

> >Example about using the API
> 
> "Example about?"

Fixed

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

The example is only about the syntax and making it real-world would
make it longer. I've added a section explaining why we need this API
with a real-world example.

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

Done. Also, note the Issues section: we *can* make it look more like the 
conventional
version in the future with some extra work.

        Tuomas