[Gridflow-dev] ping (fwd)

[Mathieu Bouchard]

---------- Forwarded message ----------
Date: Thu, 9 Sep 2004 07:18:50 +0200
From: Tom Schouten <doelie at zzz.kotnet.org>
To: Mathieu Bouchard <matju at sympatico.ca>
Subject: Re: [Gridflow-dev] ping (fwd)

On Wed, Sep 08, 2004 at 10:09:08PM -0400, Mathieu Bouchard wrote:
> 
> On Sat, 4 Sep 2004, Tom Schouten wrote:
> 
> > what i am trying to do, is to stay true to the concept and take it
> > very far. the fact that i'm dragging forth in the picture is because i
> > like it, and because there are a lot of parallels between forth and
> > unix style 'patching'.
> 
> Then I think you can make that parallel between any two sufficiently
> powerful languages, unless I'm mistaken as to the nature of Forth.
>

maybe it's about coroutines, pipes and
ls|grep|awk|sed|whatever > /dev/null

i've been doing a lot of advocating lately, and the simplest explanation
for me still is: it just works out. there are a lot of other explanations in
the pf (libpdp) documentation especially in doc/ramblings.txt and scattered 
around the libpdp code.

> > now, what's the problem with unix and media processing? meta data. it
> > is hard for programs to talk with each other, because there is not
> > really a general protocol for doing this. 'ordinary' unix works with
> > text, but doing this for practical media processing quite unrealistic.
> > there's just too much data moving about.
> 
> In (all) dataflow systems, such as Pd and UNIX, one major problem is that
> there is no primitive for return values or callbacks. This is pretty
> normal, as it's the point of the dataflow paradigm. Maybe a variant of
> dataflow could include the possibility for backward messages, that go from
> "outlets" to "inlets". I once thought about a concept of "sidelets" for

i've heard that idea before in the pd meme pool..

> that. Else the only way to achieve it seems to be to reserve inlets and
> outlets specially for messages going the other way. The best example of it
> in GridFlow is [#remap_image].
>

it seems to me you're describing systolic arrays.

i've been thinking a lot about this in relation to cellular automata,
neural networks, and other distributed systems. i really want to get this 
damn forth working so i can get on with exploring that world..
 
> > now, this diversity is important. it is one of the key things of the
> > GPL world.
> 

forgive my sloppy terminology. open source world i meant. the fairly recent
culture of wide availability of high quality source code.

> Not sure; afaik, the GPL doesn't talk about diversity, FSF/GNU don't talk
> about diversity, they only talk about freedom. 

cut n paste code is like crossing genes.
most of the diversity you don't see. it's all those people doing stuff they
never release.

the consequence of the code being there is that there's a lot of fertilizing
going on. the result is that there are several programs doing the same
thing, like you have several species of living things all competing for food,
some survive. most die and never get released. a lot of the diversity caused
by this abundance of raw material on the net you don't see.


> > pf is meant to patch this. it is supposed to be the glue to connect
> > other applications. pf is a protocol. but it is a protocol which is a
> > language (in the style of postscript) connected to other things.
> 
> There are many, many so-called "glue languages".
>

but not many that have real-time constraints built in with most of the
flexibility of lisp.

> > pf's aim is to connect things that can't be connected otherwize, but
> > that have to operate in a real-time fashon: i.e. places where you
> > can't rely on contemporary scripting languages because of the garbage
> > collector.
> 
> One of the first (maybe the first) languages to be marketed as a "glue
> language" has been TCL (1987). TCL has been tremendously popular, Pd
> depends on it already, and it doesn't use a mark-sweep style of garbage
> collection. Why choose Forth instead of Tcl ?
>

i must admit that never even crossed my mind.

not a real argument, but i don't like tcl that much. i've never found
it to be very expressive. maybe i didn't try hard enough. i used it several
times and was actually quite excited when i got to know it short after 
getting into linux.

i don't think it's very fast either. pf is not a really fast forth, but 
it's still compiled to byte code when it loads. so no parsing or symbol 
lookup overhead during execution. all pointers.

i wanted to have something under my control, of which i could choose 
certain trade-offs myself instead of depending on other people and other
application areas. this is really special purpose.