Lambda the Ultimate

So my question would be - are you using game semantics in your dissertation?

My language is based on connections as simple linking mechanisms. Because such connections are not very expressive, object-oriented mechanisms are used to organize the connections. Anyways, I finally got around to putting a paper on the web:

See
http://lamp.epfl.ch/~mcdirmid/mcdirmid06superglue.pdf for a 10,000 word paper on the language.

and

See http://lamp.epfl.ch/~mcdirmid/thesis.pdf for my dissertation.

An example of a functional reactive language is FrTime (Father Time). There is an implementation in PLT Scheme.

Dataflow concurrency has two flavors, eager and lazy (push and pull), which can be mixed together.

Is there really any difference? From the inside of a co-routine or process push and pull are indistinguishable. The important distinction to me seems to be blocking or nonblocking because that tells you which end(s) is/are in control of the flow.

I think of the difference between push and pull in terms of viewing state. "pull" allows us to get the current value of some state, while "push" allows us to be notified of changes in some state. For example, we can look at the clock to get the current time ("pull") or set an alarm to be notified when its 6 AM ("push"). I know this gets away from the traditional notion of dataflow programming, which often does not deal with state. But I've found it to be useful in extending the dataflow paradigm with support for state.

I think of the difference between push and pull in terms of viewing state. "pull" allows us to get the current value of some state, while "push" allows us to be notified of changes in some state.

This is still looking at it in terms of who calls who. You can turn pulls into pushes and vice versa by inverting who calls who. Or if you use processes then it looks to each one like they are the one calling. For example, assume you have three actors wired like this:

actorA -> actorB -> actorC

written as processes:

   void actorA(void) { while (true) { char x = getc(); send(x); }}
   void actorB(void) { while (true) { char y = receive(); send(y);  }}
   void actorC(void) { while (true) { char z = receive(); putc(z);  }}

Who is pushing and who is pulling?

the same thing written as push:

   void actorA(void) { while(true) { char x = getc(); push(x); }}
   void actorB(char y) { push(y); }
   void actorC(char z) { putc(z); }

the same thing written as pull:

   char actorA(void) { return getc(); }
   char actorB(void) { return pull(); }
   void actorC(void) { while(true) { char z = pull(); putc(z); }}

What matters is where the blocking is, not whether the implementation uses pushing, pulling or processes.

For example, we can look at the clock to get the current time ("pull")

That's not really pulling, that's polling.

set an alarm to be notified when its 6 AM ("push")

You could also pull on the condition that it is 6 AM, which will block until it is 6 AM.

At least that's the usage I'm familiar with. For me, pushing is when the process that creates or changes data propagates the new data to other processes or data structures. Examples would include SMTP, spreadsheet recalc (update propagation), materialized views, callbacks, publish-subscribe, interrupt-driven I/O.

Pull would include POP3, polling, traditional database views, top-down recalculation.

The examples you gave all count as push. There are a lot of different ways to implement push, depending on the context (same process, separate processes, over the network etc.). A blocking read, waiting for a new network connection, providing callback functions are all valid ways, but they are pointless unless there is an active process that is going to write or signal a semaphore or make a new network connection.

It may seem ambiguous in the case where the OS (or another intermediary) provides a general interface to wait for events, but I consider that a push (publish-subscribe). A process that creates a new file may not intend to push data to a process waiting on a directory change notification, but you're still limited to the events the OS provides, otherwise you have to resort to polling.

It is a bit ambiguous in the case of waiting for a particular time.

E.g., in synchronous pi calculus the sender is blocked until the receiver receives the message, in asynchronous pi calculus is is not blocked at all, and in call/return languages (functional PLs without control constructs a la call/cc) the caller is blocked until the receiver returns. In all cases we might want to call the sender a pusher, but only in the last case we can call him a puller as well (synchronous pi case is on a border). The receiver in neither case can be usefully classified as either pusher or puller, hence my first statement about (lack of) usefulnes of push/pull terminology.

I guess what I am trying to say is that push/pull terminology is good for sales persons, but not for scientists.

and in call/return languages (functional PLs without control constructs a la call/cc) the caller is blocked until the receiver returns

Is this synchronous or asynchronous because both can be simulated in this case? Though the caller is blocked which makes it synchronous, it can do something else too, in which case it is asynchronous.(Atleast in my language it has a chance of doing something else, so i assume everyone also has this feature)

Is there some formal work citing this?

I can say that it is because of message passing concurrency model, but that doesn't make it precise enough.