Sat Jul 5 15:23:17 CEST 2008

the future of PF

Been quite busy with Staapl (Brood) last half year. It looks like I'm
finally starting to understand the problem I set out to solve with PF:
build a system for prototyping + deployment in the domain of sound +
video processing. This problem was a bit more complicated than I
anticipated, but I'm getting to a point where it is possible to see
the trees through the forest.

I'm oscillating between planning complete abandonment of PF, and
trying to make the best of it. It's wade through the accumulation of
dead ends (see previous post), but maybe PF can be saved as a
stand-alone tool.

What it does right:

   * Memory management. Stacks + added GC.

   * System interface.

   * User interface: polymorphy through multiple dispatch.

What it does wrong:

   * Interpreter and type system implementation and semantics.

   * Specialization: Partial evaluation, code generation, code
     transformation through deforestation. This can probably be
     combined with a static type system to write an interface to PF
     that compiles straight code: getting rid of dynamic dispatch.

   * Create a malloc-free core: once initialization code has run, all
     non-deterministic garbage collection should be disabled, which
     means no more malloc/free or automatic GC other than the refcount
     based packet management.

What direction it should go:

   * OpenGL: the dead end. Last couple of years I've focussed more on
     OpenGL, but this has turned out to be a mistake. The real beef is
     in image processing. For OpenGL, PF is merely a scripting
     language: a place where Scheme, or at least Scheme based
     metaprogramming, is probably a better alternative. As far as I
     can see, Dave Griffiths has solved this problem with Fluxus.

   * Image processing + linear algebra.

PF fits really nice as a metaprogramming target in the 'algebra of
programs' approach I'm trying to develop (Inspired by Backus' FP).

I wonder if I can find a way to keep the system interface, and replace
all the internal parts one by one. The easiest thing to do would be to
run a metaprogrammed PF2 inside PF, reusing only system
interface. Then one by one PF's processing primitives could be
replaced by generated PF2 code, using a 'codelet cache' or something
based on LLVM.