Wed Jul 29 09:26:11 CEST 2009
Reminds me of the dataflow vs. `thread oriented' programming idea
mentioned before. In order to make DSP work for Forth, some kind of
local naming needs to be used to 1) make the random-access work. and
2) introduce concurrency in a serial language.
I'd say there is really only one way to properly program DSP code, and
that is using a dataflow language (DFL).
The point is that using Forth as a _frontend_ syntax isn't such a bad
idea. The syntax allows _programmers_ to perform extreme factoring.
DFL code is tedious to write due to explicit naming of outputs. See
the following table:
- forth / /
- expression x /
- dataflow x x
So, if you add some kind of primitive to forth that represent (local)
DFL nodes as names (one could `constant' semantics for inputs and use
the `->' operator as node single assignment)
A B + -> C
Looking at the C18 described in  the local names are actually
_streams_ or more concretely, autoincremented memory access. The rest
of the article talks about distributing an app over multiple cores.