Mon Jan 30 03:39:40 CET 2006
PF versus SC
the supercollider idea:
(A) very fast & simple audio server
(B) very convenient & flexible control language
both are tied using a messaging system (OSC)
since the B events are 1 to 3 orders of magnitude less frequent,
it is possible to trade some cycles for convenience. one of them is
clearly garbage collection, which enables lisp-like freedom, and
all kinds of neat language tricks that are not really possible
without the ability to account for cyclic graphs.
( in PF there are some cyclic graphs, though they are burried
deeply. one less burried example is 'defer'. so PF needs pointers
that can be null, or can reference a non-existing or recucled object. )
the problem i encounter is: if you enable GC, there is
no fast reuse of image packets, so this will be slow (cache misses)
and memory inefficient (huge memory usage).
the solution is to decouple both: the language should not be able
to manipulate images directly, only image manipulators.
(in SC: you cannot process audio buffers, only control synths,
which process audio buffers).
this is a real choice that has consequences everywhere:
* PF is really packet central, not processor central.
a bit like Pd. So it is really not possible to have m/s GC in the core,
only ref count based resource management.
* SC is processor central. true OO information hiding, which enables
a clear separation of memory allocation strategies for server and
so.. another view. SC client is a compiler for SC server.
SC server is the VM.
this brings me to the following possibility, to split PF into
* a true forth server with grid support (i.e. an efficent 'map' word / code gen)
* a Joy like RPN language (implemented in scheme for example)
as a client.
BUT BUT BUT!
the cut does not have to be too explicit, does it?
in light of the previous entry on bootstrapping, it should be possible to
write an reflective engine on top of the core forth that bootstraps itself
into a scheme-like eval machine...
(note: this idea is worked out in chicken & egg)