[Gridflow-dev] ping (fwd)

[Mathieu Bouchard]

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

Maybe the examples weren't complex enough for you?

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

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

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

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.



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 ?

> note that i do not use an object model for most things. pf objects in
> pd are 'emulated' as a task with a local context (dictionary).

I'm talking about something that can be used from PureData, so I don't
care that PF objects are not real objects or that you believe that they
are not real objects, because from PureData they are objects, given the
meaning of the word "Object" in the context of PureData.

Besides, if an object is emulated using something else than an object,
then the result is something that can honestly be called an object. That's
the meaning of "emulation".

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

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

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

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju