2 | Boussinot, F. Reactive C: An extension of C to program reactive systemsSoftware: Practice and Experience214 1991401--428. |
3 | Evan Czaplicki, and Stephen Chong, Asynchronous Functional Reactive Programming for GUIsProceedings of the 34th ACM SIGPLAN Conference on Programming Language Design and ImplementationNew York, NY, USAJun 2013411--422. |
4 | Friedman, D. and Wise, D. The Impact of Applicative Programming on MultiprocessingInternational Conference on Parallel Processing 1976263--272. |
PhD thesis proposal: Reactive Web Programming
Manuel Serrano, Gérard Berry
Inria Sophia Antipolis, Collège de France
Manuel.Serrano@inria.fr, Gerard.Berry@college-de-france.fr
http://www.inria.fr/indes
1Facts
2Introduction
Asynchrony being consubstantial with the Web, asynchronous
communication and control patterns are ubiquitous at multiple scales
in Web programs. They are used to program Web clients as well as Web
servers. Browser HTML GUIs raise asynchronous events in reaction to
user interactions. The Web browser DOM (Document Object Model) creates
Web page elements asynchronously. Browser-to-server (AJAX) and
server-to-server (program-as-a-service (PAAS) and Web APIs)
communications are physically asynchronous as they involve network
traversals that take wall-clock time. Web-of-things and diffuse
robotics applications that are based on device-to-machine
communications make asynchronous event raising even more frequent.
The objective of this PhD thesis is to help programming this family
of rich Web applications by creating a programming language dedicated
to deal with asynchronous events and orchestrate the tasks they
trigger or terminate. This language will rely on the former
development of synchronous languages directed towards embedded systems
(Esterel, Lustre/SCADE, etc.). Despite the apparent name antagonism,
synchronous languages are very efficient for programming complex
reactions to asynchronous events and synchronize them. They have
already be used extensively for robotics and GUI applications
(including full airplane GUIs).
3Context and Subject
Here is the state of the art w.r.t. web event handling. A myriad
of ad-hoc solutions keep emerging here and there. The popular
IFTTT1 platform relies on an overly simple
language for programming recipes. It spawns actions in reaction to
events: If This event occurs Then do That action. The
events are generated by Web applications such as Twitter, Facebook, or
other any other Web site. Typical actions are send me a text message
or create a status message on Facebook
. Although rudimentary, this
system is gaining attraction as it allows non expert users to program
simple but useful tasks. More elaborate solutions require fancier
programming languages, usually extensions of JavaScript that reigns
here unchallenged. During the last years, many JavaScript libraries
implementing asynchronous operators have been released publicly. Let
us name a few:
async2,
async.js3,
bacon.js4, RxJS
65,
slide-flow-control6,
step7. These
libraries implement asynchronous streams and some sort of
futures 4. They support higher-order stream
operators such as map, filter, and reduce. More elaborated systems
such as Flapjax 7 and Elm 3 make the
functional reactive programming (FRP) paradigm available within
JavaScript. They promote asynchronous streams to first-class values
of the language, i.e., streams can be stored into regular
data structures, passed as arguments to functions, returned as
results, and even be composed into stream of streams. Flapjax and Elm
define themselves as extensions of JavaScript, but, since they change
the meaning of the control flow operators, a compilation-to-JavaScript
phase takes place before execution.
Each of the aforementioned system or language addresses a specific
aspect of Web asynchronous programming, but none aims at offering a
universal solution to the global management and synchronization of
asynchronous events and tasks. For instance, neither the asynchronous
JavaScript libraries nor the FRP JavaScript extensions support
preemption, which limits them to crude ad-hoc solutions for dealing
with cancellations and errors. FRP design choices have another not
necessarily desirable consequence: promoting asynchronous streams as
first-class values demolishes the fences that separate the classical
algorithmic core language from its asynchronous extensions. The
genuine semantics of the core language is then altered. Flapjax and
Elm are based on JavaScript versions that obey their own semantics rules
and that differ from the official ECMAScript 5 language rules.
The synchronous programming model of languages like Esterel or
Reactive-C rely on a different form of concurrency based on the
perfect synchrony hypothesis: a synchronous reactive program
repeatedly reacts in conceptual zero-delay to input events by
generating output events or calling computation actions;
synchronization and communication between synchronous parallel
statements is also performed in conceptual zero-delay. Perfect
synchrony makes concurrent programs deterministic and deadlock-free,
the only non-determinism left being that of the application
environment. These languages are nowadays used to build complex and
critical systems such as airplane control or cockpit systems.
In the synchronous reactive programming model, two languages levels
coexist: the core algorithmic language and the orchestration
language. How these languages are exposed to the programmer varies
from one particular synchronous language to another, but all share a
strong design axiom: the core algorithmic language and the
orchestration language are separated by an hermetic membrane that can
only be traversed by well-identified operators that have clearly
(i.e., formally) established semantics. The synchronous model
is very appealing for programming the asynchronous patterns of Web
applications, because it makes synchronization trivially explicit and
deterministic, which simplifies decision taking. Synchronous languages
are much more expressive than asynchronous languages, since they
support rich concurrency and event-handling operators: parallelism,
synchronization, preemption, and exception and error handling. The
synchronous model has been extensively studied, is mathematically
well-founded, and has become an industrial standard for embedded
systems. It does not impose to create a brand new programming language
since it can be implemented as a DSL hosted by an existing algorithmic
language as already done for C 2 and
OCaml 5.
The objective of this PhD thesis is to construct a JavaScript
synchronous DSL for orchestrating Web applications. Will the language
be presented with its own syntax requiring a front-end compilation or
will it be exposed as a pure JavaScript API remains an open
choice. The former offers more flexibility in the design of the
language and probably and ease of programming. The latter is much in
line with modern practice of releasing JavaScript libraries such as
Node.js, Bower, or Grunt packages. That would make it be much easier
to deploy and more likely to attract a much larger audience, with a
potentially important impact outside the academic sphere. The previous
HipHop experiment that we have conducted for Hop environment will be
of course an important source of inspiration 1.
4References
2 | Boussinot, F. Reactive C: An extension of C to program reactive systemsSoftware: Practice and Experience214 1991401--428. |
3 | Evan Czaplicki, and Stephen Chong, Asynchronous Functional Reactive Programming for GUIsProceedings of the 34th ACM SIGPLAN Conference on Programming Language Design and ImplementationNew York, NY, USAJun 2013411--422. |
4 | Friedman, D. and Wise, D. The Impact of Applicative Programming on MultiprocessingInternational Conference on Parallel Processing 1976263--272. |
5 | Louis Mandel, and Marc Pouzet, ReactiveML, a Reactive Extension to MLMandelPouzet-PPDP-2005.pdfProceedings of 7th ACM SIGPLAN International Symposium on Principles and Practice of Declarative Programming (PPDP'05)Lisbon, PortugalJul 2005. |