Add prettier CI and run MD/MDX files through Prettier

.github/workflows/deploy.yml

@@ -49,4 +49,18 @@ jobs:
         id: deployment
         uses: actions/deploy-pages@v3
 
+  prettier-markdown:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out  repository
+        uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 18
+          cache: yarn
+      - name: Install dependencies
+        run: yarn
+      - name: Run prettier on md and mdx
+        run: npx prettier --check --prose-wrap=always "docs/**/*.md" "docs/**/*.mdx"
+
 # TODO: Deploy to some third-party place for preview?

docs/.less-developed/related-work.mdx

@@ -2,50 +2,93 @@
 title: Related Work
 description: Related Work
 ---
+
 Lingua Franca is focused more on using the best ideas than on being innovative.
-Here, we list most closely related work first, then other work with which it may be useful to contrast.
+Here, we list most closely related work first, then other work with which it may
+be useful to contrast.
 
 ## Software Frameworks
 
-* [Rubus](https://link.springer.com/article/10.1007%2Fs10270-020-00795-5).
+- [Rubus](https://link.springer.com/article/10.1007%2Fs10270-020-00795-5).
 
-* [Akka framework](https://www.sciencedirect.com/science/article/abs/pii/S0167739X20330739) for distributed Fog computing.
+- [Akka framework](https://www.sciencedirect.com/science/article/abs/pii/S0167739X20330739)
+  for distributed Fog computing.
 
-* [Accessors](http://accessors.org), from Berkeley, a JavaScript-based framework for IoT: This framework is the most direct inspiration for Lingua Franca. The idea behind accessors is to componentize IoT resources by encapsulating them in actors. As such, their interactions can be coordinated under a discrete event semantics [paper](http://www.icyphy.org/pubs/75.html).
+- [Accessors](http://accessors.org), from Berkeley, a JavaScript-based framework
+  for IoT: This framework is the most direct inspiration for Lingua Franca. The
+  idea behind accessors is to componentize IoT resources by encapsulating them
+  in actors. As such, their interactions can be coordinated under a discrete
+  event semantics [paper](http://www.icyphy.org/pubs/75.html).
 
-* [Rebecca](https://rebeca-lang.org).
+- [Rebecca](https://rebeca-lang.org).
 
-* The [Kiel Integrated Environment for Layout Eclipse Rich Client](https://www.rtsys.informatik.uni-kiel.de/en/research/kieler/welcome-to-the-kieler-project) (**KIELER**) is a graphical environment for programming using [SCCharts](https://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/SCCharts) (see the [2014 PLDI paper](https://doi.org/10.1145/2594291.2594310)).
+- The
+  [Kiel Integrated Environment for Layout Eclipse Rich Client](https://www.rtsys.informatik.uni-kiel.de/en/research/kieler/welcome-to-the-kieler-project)
+  (**KIELER**) is a graphical environment for programming using
+  [SCCharts](https://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/SCCharts)
+  (see the [2014 PLDI paper](https://doi.org/10.1145/2594291.2594310)).
 
-* **[RTMAPS](https://intempora.com/products/rtmaps#about-rtmaps)**: From Intempora. It has a graphical syntax in a UI and advertises "data is acquired asynchronously and each data sample is captured along with its time stamp at its own pace." You can build your own blocks in C++ or Python. It does, however, look like its not deterministic.
+- **[RTMAPS](https://intempora.com/products/rtmaps#about-rtmaps)**: From
+  Intempora. It has a graphical syntax in a UI and advertises "data is acquired
+  asynchronously and each data sample is captured along with its time stamp at
+  its own pace." You can build your own blocks in C++ or Python. It does,
+  however, look like its not deterministic.
 
 ### Usage of the Term Reactor
 
-* **[reactors.io](http://reactors.io/)**: This project, from EPFL, originally used the term "reactive isolates" in a [2015 paper](https://dl.acm.org/citation.cfm?doid=2814228.2814245). In 2016, Prokopec changed the name "reactive isolates" to "reactors" (see [2018 paper](http://doi.org/10.1007/978-3-030-00302-9_5)). They claim their reactors are "actors done right," but they remain nondeterministic. See a [video overview](https://www.youtube.com/watch?v=7lulYWWD4Qo).
+- **[reactors.io](http://reactors.io/)**: This project, from EPFL, originally
+  used the term "reactive isolates" in a
+  [2015 paper](https://dl.acm.org/citation.cfm?doid=2814228.2814245). In 2016,
+  Prokopec changed the name "reactive isolates" to "reactors" (see
+  [2018 paper](http://doi.org/10.1007/978-3-030-00302-9_5)). They claim their
+  reactors are "actors done right," but they remain nondeterministic. See a
+  [video overview](https://www.youtube.com/watch?v=7lulYWWD4Qo).
 
-* [Racket implementation of ReactiveML](https://docs.racket-lang.org/reactor/index.html)
+- [Racket implementation of ReactiveML](https://docs.racket-lang.org/reactor/index.html)
 
-* **FIXME** https://projectreactor.io/ based on http://www.reactive-streams.org/
+- **FIXME** https://projectreactor.io/ based on http://www.reactive-streams.org/
 
 ### Other Pointers
 
-* **[Reactive Manifesto](https://www.reactivemanifesto.org/)**: Version 2.0, Published in 2014, this position paper defines Reactive Systems as those that are Responsive, Resilient, Elastic and Message Driven.
-
+- **[Reactive Manifesto](https://www.reactivemanifesto.org/)**: Version 2.0,
+  Published in 2014, this position paper defines Reactive Systems as those that
+  are Responsive, Resilient, Elastic and Message Driven.
 
 ## Academic Projects
 
-* [I/O Automata](https://en.wikipedia.org/wiki/Input%2Foutput_automaton), from MIT, is a formalism that could be used to model the semantics of Lingua Franca. Timed I/O Automata FIXME: link extend I/O Automata with temporal semantics. They share with LF the notion of reactions to input messages and internal events that change the state of an actor and produce outputs. The behavior of a component is given as a state machine.
+- [I/O Automata](https://en.wikipedia.org/wiki/Input%2Foutput_automaton), from
+  MIT, is a formalism that could be used to model the semantics of Lingua
+  Franca. Timed I/O Automata FIXME: link extend I/O Automata with temporal
+  semantics. They share with LF the notion of reactions to input messages and
+  internal events that change the state of an actor and produce outputs. The
+  behavior of a component is given as a state machine.
 
-* **FIXME** Hewitt actors.
+- **FIXME** Hewitt actors.
 
-* **SyncCharts**: By Charles André. See the [1996 technical report](http://www-sop.inria.fr/members/Charles.Andre/CA%20Publis/SYNCCHARTS/overview.html).
+- **SyncCharts**: By Charles André. See the
+  [1996 technical report](http://www-sop.inria.fr/members/Charles.Andre/CA%20Publis/SYNCCHARTS/overview.html).
 
-* **ReactiveML**: [Website](http://reactiveml.org)
+- **ReactiveML**: [Website](http://reactiveml.org)
 
 ## Contrasting Work
 
-* [CAPH](http://caph.univ-bpclermont.fr/CAPH/CAPH.html) (a recursive acronym for CAPH Ain't plain HDL), a hardware description language from CNRS, is a fine-grained dataflow language for compiling into FPGAs. The language has no temporal semantics, and although it has a notion of firing rules, it is not clear which of the many variants of dataflow is realized nor whether the MoC is deterministic. The [paper](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6972018) does not cite any of the prior work on dataflow MoCs.
-
-* [Robot Operating System (ROS)](https://en.wikipedia.org/wiki/Robot_Operating_System), an open-source project originally from [Willow Garage](https://en.wikipedia.org/wiki/Willow_Garage): ROS provides a publish-and-subscribe server for interaction between components. Version 1 has no timing properties at all. Version 2 has some timing properties such as priorities, but it makes no effort to be deterministic.
-
-* [RADLER framework](https://sri-csl.github.io/radler/) from SRI, which is based on a publish-and-subscribe architecture similar to ROS. It introduces some timing constructs such as periodic execution and scheduling constraints, but it makes no effort to be deterministic.
+- [CAPH](http://caph.univ-bpclermont.fr/CAPH/CAPH.html) (a recursive acronym for
+  CAPH Ain't plain HDL), a hardware description language from CNRS, is a
+  fine-grained dataflow language for compiling into FPGAs. The language has no
+  temporal semantics, and although it has a notion of firing rules, it is not
+  clear which of the many variants of dataflow is realized nor whether the MoC
+  is deterministic. The
+  [paper](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6972018) does
+  not cite any of the prior work on dataflow MoCs.
+
+- [Robot Operating System (ROS)](https://en.wikipedia.org/wiki/Robot_Operating_System),
+  an open-source project originally from
+  [Willow Garage](https://en.wikipedia.org/wiki/Willow_Garage): ROS provides a
+  publish-and-subscribe server for interaction between components. Version 1 has
+  no timing properties at all. Version 2 has some timing properties such as
+  priorities, but it makes no effort to be deterministic.
+
+- [RADLER framework](https://sri-csl.github.io/radler/) from SRI, which is based
+  on a publish-and-subscribe architecture similar to ROS. It introduces some
+  timing constructs such as periodic execution and scheduling constraints, but
+  it makes no effort to be deterministic.

docs/.less-developed/timing-analysis.mdx

@@ -2,16 +2,20 @@
 title: Timing Analysis
 description: Timing Analysis.
 ---
+
 # Examples
 
 ## Precision-Timed Actuation (discussion Dec 2018)
+
 Given a time unit c,
- - H3 reacts sporadically >= 100c (e.g., 10, 120, 230, ...)
- - H4 reacts periodically with period 50c (e.g., 0, 50, 100, ...)
- - Delay adds 100c to the timestamp of each incoming event
- - Actuate shall start executing H5 _before_ r.t. clock exceeds time stamp of incoming events
-
-``` 
+
+- H3 reacts sporadically >= 100c (e.g., 10, 120, 230, ...)
+- H4 reacts periodically with period 50c (e.g., 0, 50, 100, ...)
+- Delay adds 100c to the timestamp of each incoming event
+- Actuate shall start executing H5 _before_ r.t. clock exceeds time stamp of
+  incoming events
+
+```
 +--------+
 |        |          +--------+     +-------+     +---------+
 |   H3   +----------> H1     |     |       |     |         |
@@ -28,15 +32,16 @@ Given a time unit c,
 
 We can construct a dependency graph:
 
-``` 
+```
 H3 ---> H1 ---> H2 ---> H5
             |
 H4 ---------+
-``` 
+```
 
 A feasible schedule requires that:
- - WCET(H3) + WCET(H1) + WCET(H2) \<= 100c
- - WCET(H4) + WCET(H1) + WCET(H2) \<= 100c
+
+- WCET(H3) + WCET(H1) + WCET(H2) \<= 100c
+- WCET(H4) + WCET(H1) + WCET(H2) \<= 100c
 
 ## Preemption Example
 
@@ -58,14 +63,18 @@ A feasible schedule requires that:
 
 This example needs the following:
 
- * r3 needs to preempt r1.
- * The event from GPS needs a delay of 300ms between Corr and Ctrl, so Ctrl never sees an older event.
+- r3 needs to preempt r1.
+- The event from GPS needs a delay of 300ms between Corr and Ctrl, so Ctrl never
+  sees an older event.
 
 If we want to avoid preemption, as this hurts WCET analysis:
 
- * Split reactor Corr. into three (or more) reactors and add a delay of 100 ms after each one.
+- Split reactor Corr. into three (or more) reactors and add a delay of 100 ms
+  after each one.
 
-For both solutions, the scheduler needs a "safe to process" analysis for reaction r3 to execute while r1 is
-still executing for an older time-stamped event.
+For both solutions, the scheduler needs a "safe to process" analysis for
+reaction r3 to execute while r1 is still executing for an older time-stamped
+event.
 
-Preemption can be avoided when there are enough cores (or hardware threads in PRET) available to execute r1 and r3 concurrently.
+Preemption can be avoided when there are enough cores (or hardware threads in
+PRET) available to execute r1 and r3 concurrently.

docs/.less-developed/tools.mdx

@@ -2,8 +2,12 @@
 title: Tools
 description: LF Tools.
 ---
+
 # IDE integration
-The idea is to build a language server to facilitate the integration with a variety of editors/IDEs. See [Language Server Protocol (LSP)](https://langserver.org/) for more information.
+
+The idea is to build a language server to facilitate the integration with a
+variety of editors/IDEs. See
+[Language Server Protocol (LSP)](https://langserver.org/) for more information.
 
 ```
                  +-------------------------------------+
@@ -16,4 +20,9 @@ The idea is to build a language server to facilitate the integration with a vari
                  +-------------------------------------+
 ```
 
-If the LF compiler encounters any syntax errors, it will report them to the editor (the language client). If the LF code compiles, the output will be sent to the target compiler. If the target compiler reports any errors, these, too, will be reported to the editor via the language server. The tricky part is to match target language errors to LF source locations; the language server will have to do some bookkeeping.
+If the LF compiler encounters any syntax errors, it will report them to the
+editor (the language client). If the LF code compiles, the output will be sent
+to the target compiler. If the target compiler reports any errors, these, too,
+will be reported to the editor via the language server. The tricky part is to
+match target language errors to LF source locations; the language server will
+have to do some bookkeeping.

docs/.obsolete/language-specification.md

@@ -498,7 +498,7 @@ An instance is created with the syntax:
 
 > _instance_name_ = **new** _class_name_(_parameters_);
 
-A bank with several instances can be created in one such statement, as explained in the [banks of reactors documentation](<../writing-reactors/multiports-and-banks.mdx#banks-of-reactors>).
+A bank with several instances can be created in one such statement, as explained in the [banks of reactors documentation](../writing-reactors/multiports-and-banks.mdx#banks-of-reactors).
 
 The _parameters_ argument has the form:
 

docs/.preliminary/generic-types-interfaces-and-inheritance.mdx

@@ -3,7 +3,8 @@ title: Generic Types, Interfaces, and Inheritance
 description: Generic Types, Interfaces, and Inheritance (preliminary)
 ---
 
-_The following topics are meant as collections of design ideas, with the purpose of refining them into concrete design proposals._
+_The following topics are meant as collections of design ideas, with the purpose
+of refining them into concrete design proposals._
 
 # Generics
 
@@ -18,18 +19,29 @@ reactor Foo<S, T> {
 
 ## Type Constraints
 
-We could like to combine generics with type constraints of the form `S extends Bar`, where `Bar` refers to a reactor class or interface. The meaning of extending or implementing a reactor class will mean something slightly different from what this means in the target language -- even if it features object orientation (OO).
+We could like to combine generics with type constraints of the form
+`S extends Bar`, where `Bar` refers to a reactor class or interface. The meaning
+of extending or implementing a reactor class will mean something slightly
+different from what this means in the target language -- even if it features
+object orientation (OO).
 
 # Interfaces
 
-While initially being tempted to distinguish interfaces from implementations, in an effort to promote simplicity, we (at least for the moment) propose not to. Only in case reactions and their signatures would be part of an interface and thus should be declared (without supplying an implementation) would there be a material difference between an interface and its implementation. Making reactions and their causality interfaces part of the reactor could prove useful, but it introduces a number of complications:
+While initially being tempted to distinguish interfaces from implementations, in
+an effort to promote simplicity, we (at least for the moment) propose not to.
+Only in case reactions and their signatures would be part of an interface and
+thus should be declared (without supplying an implementation) would there be a
+material difference between an interface and its implementation. Making
+reactions and their causality interfaces part of the reactor could prove useful,
+but it introduces a number of complications:
 
 - ...
 
 # Inheritance
 
 - A reactor can extend multiple base classes;
 - Reactions are inherited in the order of declaration; and
-- Equally-named ports and actions between subclass and superclass must also be equally typed.
+- Equally-named ports and actions between subclass and superclass must also be
+  equally typed.
 
 ## Example