
Synchronous languages - dkrikun
http://www-sop.inria.fr/meije/rp/ROS/Tt-SM.html
======
p4bl0
I worked on Lustre as an undergrad student in my third year of studies. The
goal of my internship was to develop a tiny system layer to allow dynamic
scheduling of Lustre tasks, rather than only having static scheduling (which
has a lot of advantage wrt formal verification possibilities). I remember
having a lot of fun doing so (partly thanks to the people I worked with, but
also because Lustre is a very cool language to play with).

My internship report, which contains a few snippets of Lustre code, is here if
anyone is interested:
[https://pablo.rauzy.name/research/undergrad/verimag.pdf](https://pablo.rauzy.name/research/undergrad/verimag.pdf)

Internship defense slides:
[https://pablo.rauzy.name/research/undergrad/verimag-
slides.p...](https://pablo.rauzy.name/research/undergrad/verimag-slides.pdf)
(ewww these colors… sorry for what 2010 me did with that).

------
akavel
What's a synchronous language? I don't see the term explained on the page

~~~
crocal
A synchronous language models everything as a mathematical function that is
completely evaluated every « tick » of a clock (hence the term synchronous).
It is very convenient for real time software: the resulting executable code is
a single function that is evaluated repeatedly against its input every t
seconds.

Disclaimer: looks easy, but if you take a few non trivial examples with
concurrent state machines and contemplate the resulting C code, you will
quickly understand why having a dedicated language is a good idea as opposed
to trying to do it by hand.

~~~
p4bl0
In addition to that it allows to have fixed and known constraints in terms of
resources. Actually the semantics and implementations of synchronous languages
enable proving a lot of safety properties using model checking. This is very
important for real time critical systems.

The paradigm is also adapted to graphical programming (using boxes and wires)
which is quite an advantage for some field of engineering where the
specialists are not programmers.

SCADE is an example of a successful industrial product that use synchronous
programming: [http://www.esterel-technologies.com/products/scade-
suite/](http://www.esterel-technologies.com/products/scade-suite/) (it is
actually more based on Lustre despite the company being called Esterel
Technologies).

------
mcguire
I've read some about Esterelle, but no other contact. Had anyone had any
experience with any of these?

One of my professors had an idea about distributed synchronous programming,
but nothing ever came of it.

~~~
p4bl0
> One of my professors had an idea about distributed synchronous programming,
> but nothing ever came of it.

It shouldn't be too difficult to distribute synchronous languages, and it is a
quite natural idea. Most have a semantics based on Kahn networks [1], which is
already a distributed model of computation :).

[1]
[https://en.wikipedia.org/wiki/Kahn_process_networks](https://en.wikipedia.org/wiki/Kahn_process_networks)

~~~
adwn
> _It shouldn 't be too difficult to distribute synchronous languages, and it
> is a quite natural idea. Most have a semantics based on Kahn networks [1],
> which is already a distributed model of computation :)._

I don't think this is correct. Kahn networks are asynchronous (and therefore
well-suited for distributed systems), but synchronous languages are – well,
synchronous.

For every pair of nodes that exchange information, there has to be a
rendezvous between them after every non-instantaneous step [1], which is
terrible for performance in a distributed system (but virtually free in
typical single-clocked, synchronous digital circuits).

[1] You can devise heuristics which reduce the frequency of those rendezvous
in some cases, but conceptually, they're still there.

~~~
p4bl0
Mh, you're right.

However, there is a notion of synchronous Kahn networks, but maybe it is only
used by functional synchronous and dataflow languages (e.g., Lucid Synchrone,
ReactiveML). Compilation of such languages involve clock calculus (i.e. typing
for scheduling) which I think makes it possible to compute the maximum size of
a queue in the network (or maybe at least guarantee that the size is
bounded?). This would mean that what you call rendezvous points would be
statically computable (in the case of pure synchronous languages it should be
easy as the maximum queue size is zero, or one depending on how we count).

Anyway, you're right that I was mistaken to think that it was an easy problem.

EDIT: Heh: [https://www.lri.fr/~mandel/papiers/MandelPlateauPouzet-
MPC-1...](https://www.lri.fr/~mandel/papiers/MandelPlateauPouzet-MPC-10.pdf)
:).

------
tsaoyu
Some examples on the usage of synchronous languages:
[http://zelus.di.ens.fr/examples.html#ex-
bouncingball](http://zelus.di.ens.fr/examples.html#ex-bouncingball)

