[Gridflow-dev] ping (fwd)

[Tom Schouten]

On Wed, Sep 15, 2004 at 01:03:58AM -0400, Mathieu Bouchard wrote:
> 
> On Tue, 14 Sep 2004, Tom Schouten wrote:
> 
> > about the knot in the control flow. i'm still trying to figure out
> > what could be gained by this. could you give a practical example of
> > that?
> 
> I gave you three examples and you said they were useless because
> you can do that using other objects. Perhaps in PDP, but in GridFlow there
> aren't any other objects to do those because you're expected to use a knot
> based on [#remap_image].
> 

i'm still quite puzzled by the syntax actually.

> Maybe the examples weren't complex enough for you?

more like the other way around.. i'm trying to find the real added
value translated to how i would do things.


 
> > it seems to me the idea to be captured is code to be sent over the wires
> > in addition to data.
> 
> Code isn't sent over the wires, it's the wire structure that causes the
> higher-order functions. An outlet has a function-pointer aspect to it
> because it's a starting point for wires and those wires lead to inlets
> which are entry points to objects.
> 


> > i had a very short discussing with cgc about pd's singlethreadedness.
> > and it's strange that we had an almost orthogonal view on things.
> 
> You don't explain _his_ position. 

his position was that the audio SHOULD have a separate thread.
i think not. so, regarding orthogonality as something that can
be measured by the interior product of 2 vectors:

> Besides there's a critical difference
> between orthogonal (90 deg apart) and opposed (180 deg apart) but without
> even an idea of the structure of space and of the angle measurement
> process, it's difficult to say "orthogonal".

yeah, i was talking about electrons..


> > i think this is one of the most elegant parts of pd. most seem to regard
> > it as a bug, but it simply avoids all problems with synchronization
> > by being explicitly serial, but looking like dataflow. it avoids feedback
> > loops the way any state machine would do this: using a register. no
> > hidden magic. i'm going to shoot anyone who tries to change that :)
> 
> Going from one thread to multiple threads is a wreckage of many basic
> assumptions used in programming. This is why so many programs and
> libraries have to be heavily modified to become multithread-safe, whereas
> most programming concepts outside of threads tend to be noninvasive. (OK,
> CALL/CC can be damn invasive too, and so can RetriableExceptions... but
> Threads deserve a special prize for that.)
>

yes. threads are a really evil concept. as is call/cc :)

it seems to me the only reason they do add value is when you have an
operating system that wants to police things. the other reason would
be blocking io. for unix and multiuser this makes sense, but most special 
purpose things just make it a lot harder. coperative multitasking is a 
lot simpler to get right and can be built write ontop of singlethreadedness 
without too much problems.


 
> > but still, i'm interested in why exactly you would sacrifice this simplictly.
> > what exactly can be gained, what can be done in a more convenient way
> > to justify this added complexity?
> 
> I don't know. Why might I want to sacrifice this simplicity, what might I
> gain, etc. ?

ok. degustibus.

 
> Besides, I was thinking of a [#thread] class that would cause supporting
> objects to serialize themselves and replicate themselves in another
> process and only run there and not in the main patch. However I'm not
> planning to implement it any time soon because there are a few outstanding
> issues with that. I don't think I talked about this [#thread] to anyone
> recently, so I wonder why you are asking about it now.
>

i'm looking into the possibility of doing something similar with pf,
in the form of a 'macro recorder'. currently the pd/pf/pdp/pidip situation
is too much of a mess to make this work.

in fact, i already have some proof of concept things, but they are all
big hacks.

 
> 
> On Tue, 14 Sep 2004, Tom Schouten wrote:
> > Matju wrote:
> > > How do _you_ solve the problem of parametrizing object classes using
> > > objects instead of atoms? AFAIK, you don't.
> > ok. i think this sort of problem i solve with iterators. most
> > 'parametrizable' things have the form of iterators when i encounter
> > them.
> 
> How do you use iterators in PureData ?
> 

in pd i don't have a clue how to do this. but in pf it is simple.

' dosomething mycontainer map

i can only pass pd atoms and packets in pd, not execution tokes
for the forth. maybe i can add that some day.


> > almost equivalent to objects except that each object can contain
> > (instance specific) code attributes in addition to instance specific
> > data attributes (both are mostly the same in forth anyway).
> 
> Do you believe that normal objects aren't supposed to contain
> instance-specific code attributes? Why would that limitation be? And then,
> do you know any languages that limits the user like that?

the reason is more reversed about me not being able to bind global
attributes to an instance in an efficient way. but it's solved now.

> > all non-locked pf objects in pd accept arbitrary forth code. so
> > sending a message 'become-something-else' would surely be possible.
> 
> What is the expected usefulness of a 'become-something-else' message?
> The message "Object>>become:" of the Smalltalk language is a precedent,
> but it isn't _so_ useful.

just the illusion of absolute power. i kinda like that :)

 
> > it's hard to think about the same thing from 2 so different view
> > points (pure OO vs forth)
> 
> After 12 years of experience in OO programming, I think my next question
> ought to be, what is pure OO ?

i don't have a clue. but it's about things with state that you can talk to
in different ways.


[ object message ]

vs

variable obj
: bound-message obj @ message ;

and only using the 'bound-message' word

there's no revolution here, but forth facilitates the last approach with
local context determined by stacks. it makes you think different,
than normal OO syntax where you always (or most of the time) have
and explicit object and message.


stretching the concept, forth is definitely OO in its most basic form, 
but more in closure style: 

each execution token has 1 code and 1 data attribute. so it's OO.
there's just no 'native' support for 1 data attribute with more code 
attributes.

not saying you cant write one, but the 1-1 closure style is simpler.
so now i take the approach of 'cooperating closures' to emulate this.
which is acually nothing more than words bound to a shared object.

the more you play with different things, 
the more everything looks the same and a lot can be identified as
religion really.