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