Re: Event based language, does it exist?

"Per Olesen" <polesen@nordija.com> pleads:
>I'm trying to find a language which is based solely on events,


gneuner@dyn.SPAMMERS.DIE.com (George Neuner) suggests:
:Third, you might look into "data flow" system architectures


I'll use this opportunity to promote dataflow, a.k.a. graph reduction.
Recent implementations are simple and practical.


An event is a call of a routine.
[A 'routine' can be a single machine instruction or a million-line program.]


The following is the main characteristic of an event:
    During its execution, an event does not communicate with other events.


Of course, the output of an event can be the input of some 'later' event.


So an event is simpler than a process. Processes communicate; events don't.




cbbrowne@knuth.brownes.org (Christopher Browne) reminds:
|I would think that you're looking for a language based fully
|on continuations;


Correct. In particular, Per wants the dataflow-style continuations
of the early versions of Cilk (http://supertech.lcs.mit.edu/cilk),
not the controlflow-style of Scheme.
NB Early Cilk is 'based solely on events' as desired by Per.


'Dataflow-style continuation' is another way of saying:
    During its execution, an event can replace itself by other events.


In other words an event can 'call' other events,
though the parent can't use the results of any child.
This implies a tail-calling style of code.


Note that the usual parent-child relationship is a form of communication
and thus isn't allowed for events.


Q: So what's the point?
A: An event is simpler than a process. Compared to a system for processes,
      a simple system can manages the events of an application.
      Such a system can provide the application with automatic
      parallelism or other execution features.
      e.g. See the paper 'Graph Reduction for Partial Evaluation'
                at http://www-zeus.desy.de/~funnel/TSIA/index.htm
                The complete C code of that paper is available at the site.
                It is the simple compiler output of Per's
                'language which is based solely on events'.




Per mentions:
>Like you have event-based programming when you do GUI programming in


I don't know of any work yet that applies recent graph reduction
to GUI, but there is some work in this direction.
e.g. Dreme: for Life in the Net, Ph.D. thesis.
          http://www.cs.nyu.edu/phd_students/fuchs
An excerpt from the www page:
    How to escape the ubiquitous GUI event loop and eliminate the tortured,
    dismembered programming style it engenders. The essential realization
    is that "reactive programming" with callbacks is really a twisted form
    of Continuation Passing Style, a source code transformation commonly
    used in compilers for functional languages.




Per assumes:
> What I'm looking for is some language based
>on events. Maybe with events as datatypes and everything.


Actually you want implicit support for events, not explicit.
i.e. Why do things yourself, when a system can do them for you.
NB An event is a call of a routine, so with with higher order routines,
      one has great support for events.


Burkhard

Return to the comp.compilers page.
Search the comp.compilers archives again.