# N. Roux: “A Beginner's Guide to Logical Relations for a Logical Framework”
Based on [“Logical Relations for a Logical Framework”](https://kwarc.info/people/frabe/Research/RS_logrels_12.pdf)(ACM Transactions on Computational Logic (2013)) by Rabe and Sojakova, Navid Roux delivered a talk and wrote a guide on motivating, introducing, and representing logical relations in the [MMT system](https://uniformal.github.io/).
LaTeX Sources are contained in [`./sources`](./sources). See [`./sources/README.md`](./sources/README.md) for building.<br>
(Note to core kwarc members: the sources are manually mirrored, hopefully consistently, at <https://gl.kwarc.info/supervision/roux_navid/-/tree/master/msc-seminar/slides-and-report>.)
## Abstract
> Logical relations are an established proof technique for deriving meta-level theorems of formal systems. For example, they have been used to prove strong normalization, type safety, and correctness
> of compiler optimizations in the setting of various type theories and lambda calculi. Theories of
> logical relations have been stated for a wide range of formal systems.
>
> To formalize formal systems themselves, logical frameworks have been sucessfully used, particularly shining when specifying syntax and deduction (e.g. using judgements-as-types and higherorder abstract syntax). And module systems over logical frameworks allow to modularly identify,
> translate, and combine full hierarchies of formal systems.
>
> How to represent logical relations in such systems is an ongoing research question. In [“Logical
> Relations for a Logical Framework”](https://kwarc.info/people/frabe/Research/RS_logrels_12.pdf) (ACM Transactions on Computational Logic (2013)), Rabe
> and Sojakova present a theory of logical relations applicable in the setting of logical frameworks
> that, when instantiated for formal systems formalized therein, gives a reasonable notion of logical
> relations within those systems.
>
> **We provide a detailed exposition of a special case, accessible to everyone familiar with basics
> of formalizing in logical frameworks.** Our exposition is embedded in a coherent narrative spanning
> from concretely motivating logical relations (by walking through a proof of strong normalization
> for the simply-typed lambda calculus) up to concretely modeling a corresponding language feature
> for the [MMT module system](https://uniformal.github.io/) over the Edinburgh Logical Framework. **The mechanics of our derived
> language feature are novel and forgo the need of introducing any logical relation-specific language
# Slides and Manuscript for “A Beginner's Guide to Logical Relations for a Logical Framework”
The main files are `slides.tex` and `report.tex`. Follow the `% !TEX TS-program` meta directive in the respective file for building.
Prebuilt PDFs can be found in `./build`:
-[latest version](./build/slides.pdf), and [same with Beamer notes](./build/slides-with-notes.pdf)
-[version presented in official talk 2021-01-27](./build/slides-2021-01-27-presented-version.pdf), and [same with Beamer notes](./build/slides-2021-01-27-presented-version-with-notes.pdf)
For the slides, there are two versions you can build: one without and one with attached Beamer notes. Comment or uncomment the respective line `\setbeameroption{show notes on second screen}` in `slides.tex` to switch between both variants.
## How to update anything (make corrections)
1. For the slides:
1. Activate notes as described above.
2. Build as hinted at above, then move `./build/slides.pdf` to `./build/slides-with-notes.pdf`.
2. For the report (aka manuscript, guide): build as hinted at above.
3. For everything: copy the updated files `./build/slides.pdf` and `./build/report.pdf` to <https://gl.kwarc.info/supervision/seminar/-/tree/master/WS2021/logrels> (as `slides.pdf` and `guide.pdf`, respectively) and keep the sources there synced with the sources here.
*```@webpage{entry:webpage}``` -- alpha[h]url, an older solution for
online citations
*```@misc{entry:web}``` -- plain BibTeX entry
*```@misc{entry:base}``` -- crossref'd by the others above, contains
common fields, not suitable for citation
# Publication Pages
We use the Travis job to generate
[publication websites](https://kwarc.github.io/bibs/) with the help of
[LaTeXML](http://dlmf.nist.gov/LaTeXML/). Additionally, we generate
specific publication pages for [KWARC members](http://kwarc.info/people/),
[KWARC projects](http://kwarc.info/projects/), and theses. This behavior is triggered by
the `pubs` key in the bibTeX entries: an entry with `pubs = {foo,bar}` will be listed in
the publication pages http://kwarc.github.io/foo and http://kwarc.github.io/bar.
## The Build Process
In a nutshell, the build process transforms `kwarcpubs.bib` and `kwarccrossrefs.bib` to LTXML format via
[LaTeXML](http://dlmf.nist.gov/LaTeXML/). Then we run the script `src/pubs/publist.xsl`
over it for all the values from the `pubs=` field in the bibTeX entries that are registered
in the `bibs.do` variable in the `Makefile`. `publist.xsl`
selects the respective items and makes a html file from that. The results are committed to
[the `gh-pages` branch](https://github.com/KWARC/bibs/tree/gh-pages) and are then hosted by GitHub.
For details see the top-level `Makefile`.
## Adding a Person or Project Page to the Publication Pages (Generation)
To add a person to the publication pages
1. update the `bib.people` or `bib.projects` variable in the top-level `Makefile` and add the username of the person or project to add
2. update the `<xsl:choose>` statement in `src/pubs/publist.xsl` to set the real name of
the person or project to be added.
Travis will re-build the web page (takes about 30 min), but you should probably test by
building locally first.
## Building locally
The website and concatenated files are generated and pushed automatically via
TRAVIS. For building locally we use a ```Makefile```. It has the following
targets:
*```all = dist```
*```dist = bib pubs```
*```bib``` Takes the individual .bib files and concatenates them into ```kwarc.bib```
*```xml``` Takes the individual .bib files and generates xml versions of them in ```dist/ltxml/*.bib.xml``` using ```latexml```. The generated files are ```.gitignore```d as users should not need them.
*```html``` Takes the generated xml files from above and uses latexml and xslt to first generate .tex files in ```dist/tex/name-type.tex``` and then html files ```dist/html/name-type.html```. Both types are gitignored. Uses an adapted version of the ```generate-pubwww``` script, now found in ```src/html/generate.html```.
*```pubs``` Takes the generated html files and builds a nice-looking bibliography in ```dist/pubs```. The output is .gitignored and intended to be committed to a gh-pages branch later on. Although that would still need an index.html, but that should not be a problem.
*```clean-bib```, ```clean-xml```, ```clean-html```, ```clean-pubs```Removes files generated by an individual target.
*```clean``` Removes **all** generated files
The ```xml``` and ```html``` targets depend on a working latexml installation. The ```html``` and ```pubs``` targets also need ```xsltproc```.
# Using this repo in a paper repository
We write most of our papers in ```git``` repositories, there it is usually a good idea to
make this repository into an external sub-repository that can be updated as necessary. In
the instructions below we assume that you - as the paper repos maintainer - want to add the
KWARC bibs as a sub-repository at path ```lib/kbibs``` from the top of the paper
repository.
## The best way for GIT
is via the ```git-subrepo``` extension of ```git```. Unfortunately this is not part of git
(yet). So you as the paper repos maintainer have to
[install it first](https://github.com/git-commands/git-subrepo#readme) if you want to
install the KWARC bibs as a subrepos. Your users do not, they will get the subrepos
automatically on ```git clone``` or ```git pull```.
1. go to the top of your paper prehistory: ```cd path/to/top``` (you can only make a
"subrepo" from there)
2. add the KWARC bibs repos as a "subrepo": ```git subrepo clone git@github.com:KWARC/bibs.git lib/kbibs```
Note that under ```git-subrepo``` the "external" is not updated automatically, a
maintainer has to "pull" it. This can be seen as a feature and not a bug (there is less of
a chance to break things).
1. go to the top of your paper repository: ```cd path/to/top``` (you can only pull from there)
2. pull the KWARC bibs repos as a "subrepo": ```git subrepo pull lib/kbibs```
To contribute changes back to the the KWARC bibs repository, you analogously do
1. go to the top of your paper prehistory: ```cd path/to/top``` (you can only push from there)
2. pull the KWARC bibs repos as a "subrepo": ```git subrepo push lib/kbibs```
easypeasy!
## The second best way for GIT
is via ```git subtree```.
1. go to the top of your paper repository: ```cd path/to/top```
2. add the KWARC bibs repos as a remote: ```git remote add kbibs
git@github.com:KWARC/bibs.git``` under the name ```kbibs```.
3. add the remote ```kbibs``` as a subtree: ```git subtree add --prefix=lib/kbibs kbibs master --squash```
(here under the path ```lib/kbibs```). The ```--squash``` reduces history noise.
When you want to update the subrepository to the newest version, you have to "subtree
pull" as above:
1. go to the top of your paper repository: ```cd path/to/top```
