<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="fr">
	<id>http://os-vps418.infomaniak.ch:1250/mediawiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Thirs</id>
	<title>Wiki du LAMA (UMR 5127) - Contributions [fr]</title>
	<link rel="self" type="application/atom+xml" href="http://os-vps418.infomaniak.ch:1250/mediawiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Thirs"/>
	<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php/Sp%C3%A9cial:Contributions/Thirs"/>
	<updated>2026-05-21T06:25:55Z</updated>
	<subtitle>Contributions</subtitle>
	<generator>MediaWiki 1.39.4</generator>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Revues,_publications_et_articles&amp;diff=13394</id>
		<title>Revues, publications et articles</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Revues,_publications_et_articles&amp;diff=13394"/>
		<updated>2021-09-14T15:57:11Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Bibliothèque universitaire */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Vous trouverez sur cette page des renseignements sur les revues électroniques proposées aux membres du LAMA ainsi que d&#039;autres sources de documentation. Nous attirons votre attention sur le fait que certains accès nous ont été accordés suite à des négociations entre le CNRS et les éditeurs. En conséquence tout abus (communication de mot de passe à des personnes extérieurs au laboratoire par exemple) mettrait en danger l&#039;accès des membres du LAMA à ces facilités.&lt;br /&gt;
&lt;br /&gt;
Malheureusement, les abonnements ne donnent souvent accès qu&#039;aux articles des dix dernières années.&lt;br /&gt;
&lt;br /&gt;
= Bibliothèque universitaire =&lt;br /&gt;
&lt;br /&gt;
Le [http://www.scd.univ-smb.fr/ Service Commun de la Documentation et des Bibliothèques Universitaires (SCDBU)] de l&#039;université peut proposer des ressources intéressantes. Il  fournit également l&#039;accès à de nombreuses [http://www.scd.univ-smb.fr/index.php/doc-num-alpha ressources numériques], dont MathSciNet.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- &lt;br /&gt;
En attendant que quelqu&#039;un repasse proprement sur cette page, je commente les lignes ci-dessous, qui sont obsolètes.&lt;br /&gt;
&lt;br /&gt;
Concrètement, cet accès se fait par l&#039;utilisation d&#039;[http://www.oclc.org/en-US/ezproxy.html EZproxy] : généralement, c&#039;est la chaîne « http://camphrier.grenet.fr/login?url= » qui doit être ajoutée avant l&#039;URL de la ressource. Par exemple :&lt;br /&gt;
* MathSciNet : http://camphrier.grenet.fr/login?url=http://ams.u-strasbg.fr/mathscinet/&lt;br /&gt;
* ScienceDirect : http://camphrier.grenet.fr/login?url=http://www.sciencedirect.com/&lt;br /&gt;
&lt;br /&gt;
Les explications du SCDBU concernant ce service de « proxy » sont disponibles sur la page http://www.scd.univ-smb.fr/index.php/ezproxy.&lt;br /&gt;
&lt;br /&gt;
En complément, le SCDBU fournit l&#039;[http://www.scd.univ-smb.fr/index.php/ezproxy#libx extension LibX pour Firefox et Google Chrome], adaptée pour l&#039;université, et qui permet :&lt;br /&gt;
* D&#039;avoir un bouton de recherche direct vers le [http://univ-smb.summon.serialssolutions.com moteur de recherche du SCDBU] ;&lt;br /&gt;
* D&#039;avoir depuis le menu contextuel (clic droit) la possibilité de recharger la page en utilisant l&#039;EZproxy.&lt;br /&gt;
&lt;br /&gt;
 --&amp;gt;&lt;br /&gt;
&lt;br /&gt;
= Mathrice =&lt;br /&gt;
&lt;br /&gt;
Le Groupement De Service Mathrice offre lui aussi un service d&#039;accès aux bases et revues auxquelles le laboratoire est abonné (EZproxy également). Il a connaissance des abonnements des laboratoires via le [http://www.rnbm.org/ Réseau National des Bibliothèques de Mathématique] (GDS 2755). Pour utiliser cet accès, connectez vous sur la rubrique « Bibliothèque numérique » de PortailMath (https://portail.math.cnrs.fr/doc) puis cliquez sur la ressource désirée.&lt;br /&gt;
&lt;br /&gt;
Ici, EZproxy fonctionne en ajoutant « .ezproxy.math.cnrs.fr » entre le nom de domaine et la fin de l&#039;URL de la ressource. Par exemple :&lt;br /&gt;
* MathSciNet : http://www.ams.org.ezproxy.math.cnrs.fr/mathscinet/&lt;br /&gt;
* EMS : http://www.ems-ph.org.ezproxy.math.cnrs.fr/journals/journals.php&lt;br /&gt;
* ScienceDirect : http://www.sciencedirect.com.ezproxy.math.cnrs.fr/&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Note&#039;&#039;&#039; : l&#039;ancien accès à ces ressources par le webmail (https://webmail.math.cnrs.fr/) ne devrait plus être utilisé, la technologie utilisée commençant à devenir obsolète et non compatible avec les éditeurs de ressources en ligne.&lt;br /&gt;
&lt;br /&gt;
Pour plus d&#039;informations sur Portail Math, vous pouvez également aller voir [https://lama.univ-savoie.fr/mediawiki/index.php/Mathrice la page du wiki consacrée].&lt;br /&gt;
&lt;br /&gt;
= BiblioST2I =&lt;br /&gt;
&lt;br /&gt;
Notre laboratoire a accès à la base documentaire BiblioST2I (Sciences et Technologies de l’Information et de l’Ingénierie), fournie par le CNRS, donnant accès à des collections inaccessibles depuis les liens précédent, notamment l&#039;ACM (i.e. la plupart des grandes revues américaines), Elsevier, etc…&lt;br /&gt;
&lt;br /&gt;
Pour y accéder, il vous faut récupérer l&#039;identifiant et le mot de passe du laboratoire disponibles sur https://lama.univ-savoie.fr/index.php?use=docelec, puis vous rendre sur http://bibliost2i.inist.fr.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Attention, l&#039;acces au portail BiblioSt2I changera le 9 Novembre 2016. Le nouveau portail s&#039;appelle &#039;&#039;&#039;BibCnrs&#039;&#039;&#039;. L&#039;accès au portail se fera via une authentification individuelle, via la base de données CNRS. Chaque membre d&#039;une UMR peut créer un compte dans cette base de données : un tutoriel est disponible ici : [http://www.inist.fr/?Comment-obtenir-un-compte-Sesame&amp;amp;lang=fr]&lt;br /&gt;
&lt;br /&gt;
De nouvelles fonctionnalités seront proposées afin d’optimiser l’intégration de BibCnrs à votre environnement numérique de travail :&lt;br /&gt;
&lt;br /&gt;
#L’identification sur un site éditeur via un signet ayant droit vous facilitera l’accès au texte intégral des articles &lt;br /&gt;
#Un paramétrage Google Scholar vous aidera à repérer les articles disponibles en texte intégral&lt;br /&gt;
&lt;br /&gt;
= CCSD =&lt;br /&gt;
&lt;br /&gt;
Le [https://www.ccsd.cnrs.fr/ CCSD] (Centre pour la Communication Scientifique Directe) est une unité mixte de service du [http://www.cnrs.fr/ CNRS], de l&#039;[http://www.inria.fr/ INRIA] et de l&#039;[http://www.universite-lyon.fr/ université de Lyon] principalement dédiée à la réalisation d’archives ouvertes. Elle propose notamment les services suivant :&lt;br /&gt;
&lt;br /&gt;
* [https://hal.archives-ouvertes.fr/ HAL] : dépôt et diffusion d&#039;articles scientifiques&lt;br /&gt;
* [https://tel.archives-ouvertes.fr/ TEL] : équivalent de HAL pour l&#039;hébergement de thèse&lt;br /&gt;
* [http://episciences.org/ Episciences.org] : plate-forme d&#039;examen d&#039;articles par les pairs, dans le but de créer des revues en libre accès&lt;br /&gt;
* [https://medihal.archives-ouvertes.fr/ MédiHAL] : archive ouverte de photographies et d&#039;images scientifiques&lt;br /&gt;
* [http://heloise.ccsd.cnrs.fr/ HELOISE] : service d’information sur les politiques des éditeurs en matière de dépôt des articles&lt;br /&gt;
* [[ScienceConf.org|Scienconf.org]] : création simple de sites web pour l&#039;organisation de colloques&lt;br /&gt;
&lt;br /&gt;
= Autres ressources gratuites =&lt;br /&gt;
&lt;br /&gt;
* L&#039;incontournable site du Réseau National des Bibliothèques de Mathématiques (RNMB) avec tout ses liens vers des revues numérisées : http://www.rnbm.org&lt;br /&gt;
* Le site de préprint Archive : http://arxiv.org/archive/math&lt;br /&gt;
* Un site lien sur des revues polonaises gratuites : http://matwbn.icm.edu.pl/index.php?jez=en&lt;br /&gt;
* Les liens de l&#039;AMS : http://www.ams.org/samplings/math-history/math-history&lt;br /&gt;
* Numdam (Numérisation de documents anciens en mathématiques) : http://www.numdam.org&lt;br /&gt;
* Le projet Euclide : http://projecteuclid.org&lt;br /&gt;
&lt;br /&gt;
= Qui paye quoi ? =&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;À compléter !&#039;&#039;&#039;&lt;br /&gt;
*Le [http://www.scd.univ-smb.fr/ SCDBU] de l&#039;université finance la majorité des ressources ainsi que l&#039;EZproxy pour y accéder.&lt;br /&gt;
*Le laboratoire paye un abonnement à MathSciNet.&lt;br /&gt;
*L&#039;abonnement à l&#039;EMS est payé par l&#039;[http://www.cnrs.fr/insmi/ INSMI] (Institut National des Sciences Mathématiques et de leurs Interactions).&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Synchronisation_des_fichiers_entre_plusieurs_machines_:_Unison&amp;diff=13367</id>
		<title>Synchronisation des fichiers entre plusieurs machines : Unison</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Synchronisation_des_fichiers_entre_plusieurs_machines_:_Unison&amp;diff=13367"/>
		<updated>2021-08-02T15:56:02Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Versions et compatibilité */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Unison permet de synchroniser des fichiers entre deux machines. Avec [[Mathrice#PLMbox|PLMBox]] et [[MyCore : owncloud du CNRS|Mycore]], c&#039;est l&#039;un des moyens recommandé pour synchroniser vos documents entre le serveur et votre ordinateur portable (ou votre ordinateur fixe s&#039;il n&#039;utilise pas OpenAFS), et ainsi bénéficier d&#039;une sauvegarde.&lt;br /&gt;
&lt;br /&gt;
* Site officiel : http://www.cis.upenn.edu/~bcpierce/unison/index.html&lt;br /&gt;
* Forge : https://github.com/bcpierce00/unison&lt;br /&gt;
* Groupe Yahoo : https://groups.yahoo.com/neo/groups/unison-users/info&lt;br /&gt;
&lt;br /&gt;
= Versions et compatibilité =&lt;br /&gt;
&lt;br /&gt;
Au LAMA, il y a un serveur dédié pour faire la synchronisation de vos fichiers avec unison :&lt;br /&gt;
* lama-unison3.local.univ-smb.fr / 192.168.144.17 &lt;br /&gt;
&lt;br /&gt;
Par défaut, Unison refusera de synchroniser si les versions clientes et serveur ne sont pas les mêmes.&lt;br /&gt;
&lt;br /&gt;
Sur le serveur lama-unison3.local.univ-savoie.fr&lt;br /&gt;
*2.48&lt;br /&gt;
&lt;br /&gt;
= Installation =&lt;br /&gt;
&lt;br /&gt;
== Sous Linux ==&lt;br /&gt;
Testé avec Debian 8 Jessie.&lt;br /&gt;
&lt;br /&gt;
Si la machine a été installée par les techniciens du laboratoire, Unison est normalement déjà installé.&lt;br /&gt;
Sinon, sous Debian / Ubuntu / Mint, installer le paquet &amp;quot;unison-gtk&amp;quot; :&lt;br /&gt;
&amp;lt;code&amp;gt;# apt-get install unison-gtk&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# unison &amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Cliquer sur &amp;quot;Ajouter&amp;quot; pour créer un profil, et renseigner les informations demandées :&lt;br /&gt;
* &amp;quot;Profile name&amp;quot; : un nom de profil arbitraire, par exemple &amp;quot;Lama&amp;quot;&lt;br /&gt;
* &amp;quot;Description&amp;quot; : si vous le souhaitez, tapez une description&lt;br /&gt;
* &amp;quot;Synchronization kind&amp;quot; : &amp;quot;Using SSH&amp;quot;&lt;br /&gt;
* &amp;quot;Host&amp;quot; : lama.univ-savoie.fr&lt;br /&gt;
* &amp;quot;User&amp;quot; : votre nom d&#039;utilisateur sur le serveur (dans mon cas, &amp;quot;ymass&amp;quot;)&lt;br /&gt;
* Décocher la case &amp;quot;Enable compression&amp;quot; puis cliquer sur suivant&lt;br /&gt;
* &amp;quot;Local directory&amp;quot; : le répertoire local que vous voulez synchroniser avec le serveur&lt;br /&gt;
* &amp;quot;Remote directory&amp;quot; : le répertoire sur le serveur que vous souhaitez synchroniser, par exemple &amp;quot;/home/ymass/Documents&amp;quot; (sans les guillemets)&lt;br /&gt;
* Cliquer sur &amp;quot;Suivant&amp;quot;&lt;br /&gt;
* Décocher la case &amp;quot;Synchronization involving a FAT partition&amp;quot;, puis cliquer sur &amp;quot;Suivant et finalement &amp;quot;Appliquer&amp;quot;&lt;br /&gt;
&lt;br /&gt;
* Cliquer sur le nom du profil puis sur &amp;quot;Ouvrir&amp;quot;&lt;br /&gt;
* Une pop-up s&#039;affiche la première fois pour vous demander si vous souhaitez vous connecter avec le serveur, confirmer.&lt;br /&gt;
* Taper le mot de passe de votre compte sur le serveur, et patienter le temps qu&#039;Unison compare les répertoires local et distant.&lt;br /&gt;
* Une autre pop-up s&#039;affiche pour vous prévenir que c&#039;est la première synchronisation, cliquer sur &amp;quot;Valider&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== Windows ==&lt;br /&gt;
Testé avec Windows 7 64 bits.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Attention : cette méthode enregistre votre mot de passe du serveur en clair sur votre poste&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Installer GTK+ pour Windows :&lt;br /&gt;
* Télécharger le logiciel depuis http://sourceforge.net/projects/gtk-win&lt;br /&gt;
* Pendant l&#039;installation, à l&#039;étape &amp;quot;Choose Components&amp;quot;, cocher tout. Laisser le reste par défaut.&lt;br /&gt;
&lt;br /&gt;
Télécharger Unison à l&#039;adresse http://unison-binaries.inria.fr/, en choisissant la version stable la plus haute parmi les version 2.40.x.&lt;br /&gt;
* Extraire l&#039;archive .zip : clic droit -&amp;gt; &amp;quot;Extraire tout...&amp;quot;, puis valider en cliquant sur le bouton &amp;quot;Extraire&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Lancer le logiciel en double cliquant sur l&#039;exécutable dont le nom se termine par &amp;quot;GTK&amp;quot; :&lt;br /&gt;
* Cliquer sur &amp;quot;Ajouter&amp;quot; pour créer un profil, et renseigner les informations demandées :&lt;br /&gt;
* &amp;quot;Profile name&amp;quot; : un nom de profil arbitraire, par exemple &amp;quot;Lama&amp;quot;&lt;br /&gt;
* &amp;quot;Description&amp;quot; : si vous le souhaitez, tapez une description&lt;br /&gt;
* &amp;quot;Synchronization kind&amp;quot; : &amp;quot;Using SSH&amp;quot;&lt;br /&gt;
* &amp;quot;Host&amp;quot; : lama.univ-savoie.fr&lt;br /&gt;
* &amp;quot;User&amp;quot; : votre nom d&#039;utilisateur sur le serveur (dans mon cas, &amp;quot;ymass&amp;quot;)&lt;br /&gt;
* Décocher la case &amp;quot;Enable compression&amp;quot;&lt;br /&gt;
* &amp;quot;Local directory&amp;quot; : le répertoire local que vous voulez synchroniser avec le serveur, par exemple &amp;quot;C:\Users\toto\Documents\&amp;quot;&lt;br /&gt;
* &amp;quot;Remote directory&amp;quot; : le répertoire sur le serveur que vous souhaitez synchroniser, par exemple &amp;quot;/home/ymass/Documents&amp;quot; (sans les guillemets)&lt;br /&gt;
* Fermer Unison&lt;br /&gt;
&lt;br /&gt;
Télécharger l&#039;utilitaire plink.exe (un des composants du célèbre Putty) depuis http://the.earth.li/~sgtatham/putty/latest/x86/plink.exe&lt;br /&gt;
* Le placer dans le même dossier que l&#039;exécutable Unison&lt;br /&gt;
* Dans l&#039;ex menu &amp;quot;Démarrer&amp;quot; chercher le programme &amp;quot;cmd&amp;quot; et le lancer&lt;br /&gt;
* Lancer une première connexion SSH au serveur afin d&#039;accepter le certificat, en utilisant la commande suivante : &amp;lt;code&amp;gt;chemin_répertoire_Unison\plink.exe nom_utilisateur_serveur@lama.univ-savoie.fr -ssh&amp;lt;/code&amp;gt;&lt;br /&gt;
* Accepter la clé en tapant &amp;quot;y&amp;quot; puis la touche &amp;quot;Entrée&amp;quot;, puis annuler la commande avec le raccourci &amp;quot;Ctrl+C&amp;quot;&lt;br /&gt;
* Fermer la fenêtre d&#039;invite de commande.&lt;br /&gt;
&lt;br /&gt;
Éditer le fichier .prf contenant les paramètres du profil Unison que nous venons de créer, situé dans le répertoire .unison, à la racine de votre répertoire personnel.&lt;br /&gt;
* Faire un clic droit dessus et aller dans &amp;quot;Ouvrir avec...&amp;quot;&lt;br /&gt;
* Cliquer sur la flèche à droite de &amp;quot;Autres programmes&amp;quot; et choisir &amp;quot;Bloc-Notes&amp;quot;, puis valider avec le bouton &amp;quot;OK&amp;quot;&lt;br /&gt;
* Ajouter la ligne : &amp;lt;code&amp;gt;sshcmd = plink-ssh-command.bat&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Toujours dans le Bloc-notes, créer ce .bat en allant dans &amp;quot;Fichier&amp;quot; -&amp;gt; Nouveau&amp;quot;&lt;br /&gt;
* Y placer la ligne suivante : &amp;lt;code&amp;gt;@plink.exe num_utilisateur_serveur@lama.univ-savoie.fr -ssh -pw mot_de_passe_serveur &amp;quot;unison -server -contactquietly&amp;quot;&amp;lt;/code&amp;gt;&lt;br /&gt;
* Enregistrer ce fichier dans le répertoire contenant l&#039;exécutable d&#039;Unison, en lui donnant pour nom &amp;quot;plink-ssh-command.bat&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Finalement, relancer Unison, en double cliquant sur l&#039;exécutable dont le nom se termine par &amp;quot;GTK&amp;quot; :&lt;br /&gt;
* Cliquer sur le nom du profil puis sur &amp;quot;Ouvrir&amp;quot;&lt;br /&gt;
* Une pop-up s&#039;affiche pour vous prévenir que c&#039;est la première synchronisation, cliquer sur &amp;quot;Valider&amp;quot;&lt;br /&gt;
* Patienter le temps qu&#039;Unison compare les répertoires local et distant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Il est ensuite fortement conseillé de lire le paragraphe ci-dessous de configuration &amp;quot;avancée&amp;quot; : cela vous permettra par exemple de ne pas synchroniser les fichiers temporaires créés lors des compilations LaTeX, de ne pas mettre vos photos de vacances sur le serveur, etc...&lt;br /&gt;
&lt;br /&gt;
== Mac OSX ==&lt;br /&gt;
Testé avec OSX 10.8.5&lt;br /&gt;
&lt;br /&gt;
Télécharger le logiciel à l&#039;adresse http://unison-binaries.inria.fr/ :&lt;br /&gt;
* Choisir la version :&lt;br /&gt;
** Au moins pour OSX 10.8 et 10.10, choisir la version 2.40.61 (la version 2.40.69 plante à la connexion au serveur).&lt;br /&gt;
* Installer l&#039;application comme d&#039;habitude, en la faisant glisser dans le répertoire Applications.&lt;br /&gt;
* Au lancement de l&#039;application, Unison vous demande si vous souhaitez installer l&#039;utilitaire en ligne de commande : ce n&#039;est pas nécessaire.&lt;br /&gt;
* Cliquer sur le bouton &amp;quot;New&amp;quot; pour créer un profil, puis renseigner les informations demandées :&lt;br /&gt;
** &amp;quot;Profile name&amp;quot; : un nom de profil arbitraire, par exemple &amp;quot;Lama&amp;quot;&lt;br /&gt;
** &amp;quot;First root&amp;quot;, &amp;quot;File&amp;quot; : le chemin du répertoire local que vous voulez synchroniser avec le serveur, par exemple &amp;quot;/Users/yvan/Documents/Recherche&amp;quot; (sans les guillemets)&lt;br /&gt;
** &amp;quot;Second root&amp;quot; :&lt;br /&gt;
*** Laisser cochée la case &amp;quot;Remote&amp;quot;&lt;br /&gt;
*** &amp;quot;User&amp;quot; : votre nom d&#039;utilisateur sur le serveur (dans mon cas, &amp;quot;ymass&amp;quot;)&lt;br /&gt;
*** &amp;quot;Host&amp;quot; : lama.univ-savoie.fr&lt;br /&gt;
*** &amp;quot;File&amp;quot; : le chemin du répertoire sur le serveur que vous souhaitez synchroniser, par exemple &amp;quot;/home/ymass/Documents&amp;quot; (sans les guillemets)&lt;br /&gt;
** Cliquer sur le bouton &amp;quot;Save&amp;quot; en haut de la fenêtre, puis sur le bouton &amp;quot;Open&amp;quot;.&lt;br /&gt;
* Une pop-up s&#039;affiche la première fois pour vous demander si vous souhaitez vous connecter avec le serveur, confirmer.&lt;br /&gt;
* Taper le mot de passe de votre compte sur le serveur, et patienter le temps qu&#039;Unison compare les répertoires local et distant.&lt;br /&gt;
&lt;br /&gt;
Il est ensuite fortement conseillé de lire le paragraphe ci-dessous de configuration &amp;quot;plus fine&amp;quot; : cela vous permettra par exemple de ne pas synchroniser les fichiers temporaires créés lors des compilations LaTeX, de ne pas mettre vos photos de vacances sur le serveur, etc...&lt;br /&gt;
&lt;br /&gt;
= Configuration &amp;quot;plus fine&amp;quot; = &lt;br /&gt;
&lt;br /&gt;
Unison utilise un fichier de configuration &amp;quot;XXX.prf&amp;quot; (XXX est le nom que vous donnez au profile), qui est créé quand on utilise l&#039;interface graphique. Toutefois, de nombreuses options très utiles doivent être ajoutées à la main dans le fichier.&lt;br /&gt;
&lt;br /&gt;
Celui-ci se trouve dans le répertoire &amp;quot;.unison&amp;quot; à la racine du dossier personnel sous Linux et Windows et dans &amp;quot;Library/Application Support/Unison&amp;quot; sur OSX.&lt;br /&gt;
&lt;br /&gt;
En voici une configuration recommandée type au LAMA (il faut la modifier en fonction de vos besoins&lt;br /&gt;
en particulier les &amp;quot;roots&amp;quot;, le nom du serveur (attention alors au username/passwd)) :&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
  # répertoire sur le client, ici tout le répertoire utilisateur de &amp;quot;username&amp;quot; (pour un poste Linux)&lt;br /&gt;
  root = /home/username/ &lt;br /&gt;
  # répertoire sur le serveur du lama (idem ici tout)&lt;br /&gt;
  root = ssh://username@www.lama.univ-savoie.fr//home/raffalli/ &lt;br /&gt;
  &lt;br /&gt;
  follow = Path WWW # on veut suivre le raccourci WWW pour synchroniser aussi sa page web perso&lt;br /&gt;
  maxthreads = 1    # évite de trop charger le serveur&lt;br /&gt;
  rsrc = false      # utile si vous travaillez avec des machines OS X et d&#039;autres qui ne le sont pas&lt;br /&gt;
  &lt;br /&gt;
  # si vous ne voulez pas synchroniser tous les dossiers dans les racines spécifiées ci dessus&lt;br /&gt;
  # vous pouvez spécifier ceux que vous voulez synchroniser :&lt;br /&gt;
  path=Bibliographie&lt;br /&gt;
  path=Rapports&lt;br /&gt;
  path=Articles&lt;br /&gt;
  &lt;br /&gt;
  # Si vous voulez ignorer certains fichiers :&lt;br /&gt;
  # Ceci peut se faire, en partie, depuis l&#039;interface graphique d&#039;Unison, dans le menu &amp;quot;Ignore&amp;quot;&lt;br /&gt;
  ignore = Path .unison # ignore un fichier depuis la racine&lt;br /&gt;
  ignore = Name core    # ignore tous les fichiers qui s&#039;appellent core&lt;br /&gt;
  ignore = Name *.log   # ignore tous les fichiers qui ont l&#039;extension .log&lt;br /&gt;
  &lt;br /&gt;
  # Remarque importante :&lt;br /&gt;
  # La version d&#039;Unison doit être la même sur les 2 machines : si besoin, on peut &lt;br /&gt;
  # utiliser une ligne de ce type pour préciser la version à utiliser sur le serveur&lt;br /&gt;
  # servercmd=/usr/local/bin/unison-2.27&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Pour une configuration plus élaborée (comme par exemple l&#039;utilisation de plusieurs fichiers de configuration différents), consultez la documentation officielle (http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html).&lt;br /&gt;
&lt;br /&gt;
Pour éviter de taper le mot de passe à chaque synchronisation aller voire [[SshAvecAfs]].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=VISI201_CMI_:_visite_de_laboratoire&amp;diff=9909</id>
		<title>VISI201 CMI : visite de laboratoire</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=VISI201_CMI_:_visite_de_laboratoire&amp;diff=9909"/>
		<updated>2017-03-28T10:41:07Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* Cours du semestre 2 du parcours CMI Informatique (licence INFO).&lt;br /&gt;
&lt;br /&gt;
* Responsables pour 2016--2017: Jacques-Olivier Lachaud&lt;br /&gt;
&lt;br /&gt;
= Contenu (2016-2017) =&lt;br /&gt;
&lt;br /&gt;
Une partie de ce module consiste à assister à des séminaires dédiés aux étudiants CMI Informatique et Mathématique (1 fois par mois, les jeudi après-midi). [[http://www.lama.univ-savoie.fr/index.php?use=seminaires&amp;amp;&amp;amp;lang=fr&amp;amp;equipe=cmi&amp;amp;annee=1&amp;amp;lang=fr Planning des séminaires CMI]]&lt;br /&gt;
&lt;br /&gt;
Ces séminaires &amp;quot;grand public&amp;quot; portent sur des sujets variées en informatique et mathématiques.&lt;br /&gt;
&lt;br /&gt;
Les étudiants choisissent ensuite d&#039;approfondir un sujet, dans la liste proposée ci-dessous, ou un sujet motivé de leur choix (en accord avec le responsable du module). Ce travail personnel tuteuré donne lieu à la rédaction d&#039;une synthèse sur le sujet sous forme d&#039;une page wiki/web, ainsi que d&#039;un mini-exposé.&lt;br /&gt;
&lt;br /&gt;
= Sujets proposés (2016-2017) =&lt;br /&gt;
&lt;br /&gt;
== Algorithme de rendu de scène 3D par Z-buffer ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur: Jacques-Olivier Lachaud&lt;br /&gt;
* Résumé: Le Z-buffer est un algorithme classique de rendu de scène 3D. C&#039;est celui (avec quelques variantes) qui est implémenté dans nos cartes graphiques 3D et qui permet de visualiser des scènes extrêmement complexes en temps réel (typiquement 24 image/s).&lt;br /&gt;
* Objectifs: &lt;br /&gt;
*# décrire le principe de la projection 3D vers 2D&lt;br /&gt;
*# décrire la rastérisation des triangles sur une image en pixel&lt;br /&gt;
*# expliquer le principe du Z-buffer qui permet de gérer le fait que certains objets sont cachés par d&#039;autres&lt;br /&gt;
*# expliquer comment les couleurs sont calculées par pixel&lt;br /&gt;
*# indiquer les qualités et limitations de l&#039;algorithme&lt;br /&gt;
* Pour aller plus loin&lt;br /&gt;
*# mettre du code démo (WebGL) avec quelques explications sur le pipeline graphique OpenGL&lt;br /&gt;
*# expliquer comment on peut utiliser cet algorithme pour calculer des ombres (shadow map)&lt;br /&gt;
* Liens pour démarrer&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Z-buffer Wikipedia]]&lt;br /&gt;
** [[https://www.scratchapixel.com/lessons/3d-basic-rendering/rasterization-practical-implementation/overview-rasterization-algorithm Scratch a pixel]]&lt;br /&gt;
&lt;br /&gt;
== Traitement d&#039;image ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur: Jacques-Olivier Lachaud&lt;br /&gt;
* Résumé: Le traitement d&#039;image rassemble tous les algorithmes utilisés pour transformer les images, les améliorer, éliminer certaines perturbations, augmenter ou diminuer le contraste, changer les couleurs vers d&#039;autres couleurs, éliminer le flou ou les yeux rouges, faire du cartooning pour un rendu moins photo-réaliste, etc.&lt;br /&gt;
* Objectifs:&lt;br /&gt;
*# identifier les grandes familles de traitement: restauration, égalisation, élimination du flou de déplacement, segmentation, etc&lt;br /&gt;
*# identifier les grandes familles de techniques: filtrage spatial, filtrage fréquentiel, optimisation, etc&lt;br /&gt;
*# comprendre les points communs et différences entre le traitement des images noir et blanc et le traitement des images couleurs.&lt;br /&gt;
*# choisir un ou deux algorithmes de traitement et les expliquer en détails&lt;br /&gt;
* Pour aller plus loin&lt;br /&gt;
*# Coder un algorithme de traitement d&#039;image simple (e.g, un filtrage médian, ou un algo qui transporte les couleurs d&#039;une photo vers une autre photo)&lt;br /&gt;
&lt;br /&gt;
* Liens pour démarrer&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Traitement_d%27images Wikipedia]]&lt;br /&gt;
** [[http://www.ipol.im/ Image Processing on line]] (permet de tester en ligne des algorithmes sur vos images)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Nim et la théorie des jeux impartiaux ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur: Pierre Hyvernat&lt;br /&gt;
&lt;br /&gt;
* Le jeu de Nim (aussi appelé jeu des allumettes) est l&#039;un des premiers jeux ayant été analysé mathématiquement (par Charles Bouton en 1901). Les stratégies gagnantes peuvent être calculées en utilisant le développement en base 2 des nombres, et l&#039;opération d&#039;&amp;quot;addition de Nim&amp;quot; (XOR). La théorie de ce type de jeux (jeux &amp;quot;impartiaux&amp;quot;) est assez simple, mais de nombreuses instances de jeux sont encore non résolues.&lt;br /&gt;
* Objectifs:&lt;br /&gt;
*# comprendre la théorie du jeu de Nim (et la programmer)&lt;br /&gt;
*# comprendre le théorème de Sprague Grundy qui montre que tout jeu impartial est équivalent à un jeu de nim&lt;br /&gt;
*# regarder quelques autres exemples de tels jeux : jeu de Nim déguisés, ou jeux véritablement différents&lt;br /&gt;
*# programmer une version naịve de recherche de stratégie basée sur le théorème de Sprague-Grundy pour quelques jeux&lt;br /&gt;
&lt;br /&gt;
* Liens pour commencer&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Jeux_de_Nim jeu de Nim]]&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_de_Sprague-Grundy théorème de Sprague Grundy]]&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Jeu_de_Grundy jeu de Grundy]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== La suite de Conway et la classification périodique des &amp;quot;éléments&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur : Pierre Hyvernat&lt;br /&gt;
* La suite de Conway est la suite suivante : 1 ; 11 ; 21 ; 1211 ; 111221 ; ... Chaque terme est obtenu en &amp;quot;lisant&amp;quot; le terme précédent.                                                                                                                                                            &lt;br /&gt;
** &amp;quot;1&amp;quot; : un &amp;quot;1&amp;quot; -&amp;gt; 11&lt;br /&gt;
** &amp;quot;11&amp;quot; : deux &amp;quot;1&amp;quot; -&amp;gt; 21&lt;br /&gt;
** &amp;quot;21&amp;quot; : un &amp;quot;2&amp;quot;, un &amp;quot;1&amp;quot; -&amp;gt; 1211&lt;br /&gt;
** &amp;quot;1211&amp;quot; : un &amp;quot;1&amp;quot;, un &amp;quot;2&amp;quot;, deux &amp;quot;1&amp;quot; -&amp;gt; 111221&lt;br /&gt;
** etc.&lt;br /&gt;
Cette suite possède des propriétés étonantes données par le théorème &amp;quot;chimique&amp;quot;, le théorème &amp;quot;arithmétique&amp;quot; et le théorème &amp;quot;cosmologique&amp;quot;.&lt;br /&gt;
* Objectifs :                                                                                                                                                                                                                  &lt;br /&gt;
*# comprendre les énoncés de ces théorèmes, et l&#039;idée de la preuve du premier.                    &lt;br /&gt;
*# programmer la suite de Conway pour retrouver la classification des &amp;quot;atomes&amp;quot;&lt;br /&gt;
*# écrire un programme pour calculer expérimentalement une approximation de la constante &amp;quot;lambda&amp;quot; ainsi que des fréquences respectives des différents atomes.&lt;br /&gt;
*# écrire un programme pour calculer la suite de Robinson, une variante plus simple de la suite de Conway&lt;br /&gt;
&lt;br /&gt;
* Liens pour commencer&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Suite_de_Conway suite de Conway]]&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Suite_de_Robinson suite de Robinson]]&lt;br /&gt;
&lt;br /&gt;
== Initiation à la démonstration sur ordinateur et certification de logiciel ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur: Tom Hirschowitz&lt;br /&gt;
* Résumé: [[https://coq.inria.fr Coq]] est un logiciel de mathématiques sur ordinateur, grâce auquel des programmes élaborés ont pu être certifiés ces dernières années.&lt;br /&gt;
* Objectifs: &lt;br /&gt;
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,&lt;br /&gt;
*# programmer certaines démonstrations basiques en Coq,&lt;br /&gt;
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],&lt;br /&gt;
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l&#039;intérêt de l&#039;étudiant, étude des fondements mathématiques de Coq.&lt;br /&gt;
* Liens pour démarrer&lt;br /&gt;
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]&lt;br /&gt;
** [[https://coq.inria.fr Coq]]&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=VISI201_CMI_:_visite_de_laboratoire&amp;diff=9908</id>
		<title>VISI201 CMI : visite de laboratoire</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=VISI201_CMI_:_visite_de_laboratoire&amp;diff=9908"/>
		<updated>2017-03-28T10:38:52Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* Cours du semestre 2 du parcours CMI Informatique (licence INFO).&lt;br /&gt;
&lt;br /&gt;
* Responsables pour 2016--2017: Jacques-Olivier Lachaud&lt;br /&gt;
&lt;br /&gt;
= Contenu (2016-2017) =&lt;br /&gt;
&lt;br /&gt;
Une partie de ce module consiste à assister à des séminaires dédiés aux étudiants CMI Informatique et Mathématique (1 fois par mois, les jeudi après-midi). [[http://www.lama.univ-savoie.fr/index.php?use=seminaires&amp;amp;&amp;amp;lang=fr&amp;amp;equipe=cmi&amp;amp;annee=1&amp;amp;lang=fr Planning des séminaires CMI]]&lt;br /&gt;
&lt;br /&gt;
Ces séminaires &amp;quot;grand public&amp;quot; portent sur des sujets variées en informatique et mathématiques.&lt;br /&gt;
&lt;br /&gt;
Les étudiants choisissent ensuite d&#039;approfondir un sujet, dans la liste proposée ci-dessous, ou un sujet motivé de leur choix (en accord avec le responsable du module). Ce travail personnel tuteuré donne lieu à la rédaction d&#039;une synthèse sur le sujet sous forme d&#039;une page wiki/web, ainsi que d&#039;un mini-exposé.&lt;br /&gt;
&lt;br /&gt;
= Sujets proposés (2016-2017) =&lt;br /&gt;
&lt;br /&gt;
== Algorithme de rendu de scène 3D par Z-buffer ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur: Jacques-Olivier Lachaud&lt;br /&gt;
* Résumé: Le Z-buffer est un algorithme classique de rendu de scène 3D. C&#039;est celui (avec quelques variantes) qui est implémenté dans nos cartes graphiques 3D et qui permet de visualiser des scènes extrêmement complexes en temps réel (typiquement 24 image/s).&lt;br /&gt;
* Objectifs: &lt;br /&gt;
*# décrire le principe de la projection 3D vers 2D&lt;br /&gt;
*# décrire la rastérisation des triangles sur une image en pixel&lt;br /&gt;
*# expliquer le principe du Z-buffer qui permet de gérer le fait que certains objets sont cachés par d&#039;autres&lt;br /&gt;
*# expliquer comment les couleurs sont calculées par pixel&lt;br /&gt;
*# indiquer les qualités et limitations de l&#039;algorithme&lt;br /&gt;
* Pour aller plus loin&lt;br /&gt;
*# mettre du code démo (WebGL) avec quelques explications sur le pipeline graphique OpenGL&lt;br /&gt;
*# expliquer comment on peut utiliser cet algorithme pour calculer des ombres (shadow map)&lt;br /&gt;
* Liens pour démarrer&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Z-buffer Wikipedia]]&lt;br /&gt;
** [[https://www.scratchapixel.com/lessons/3d-basic-rendering/rasterization-practical-implementation/overview-rasterization-algorithm Scratch a pixel]]&lt;br /&gt;
&lt;br /&gt;
== Traitement d&#039;image ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur: Jacques-Olivier Lachaud&lt;br /&gt;
* Résumé: Le traitement d&#039;image rassemble tous les algorithmes utilisés pour transformer les images, les améliorer, éliminer certaines perturbations, augmenter ou diminuer le contraste, changer les couleurs vers d&#039;autres couleurs, éliminer le flou ou les yeux rouges, faire du cartooning pour un rendu moins photo-réaliste, etc.&lt;br /&gt;
* Objectifs:&lt;br /&gt;
*# identifier les grandes familles de traitement: restauration, égalisation, élimination du flou de déplacement, segmentation, etc&lt;br /&gt;
*# identifier les grandes familles de techniques: filtrage spatial, filtrage fréquentiel, optimisation, etc&lt;br /&gt;
*# comprendre les points communs et différences entre le traitement des images noir et blanc et le traitement des images couleurs.&lt;br /&gt;
*# choisir un ou deux algorithmes de traitement et les expliquer en détails&lt;br /&gt;
* Pour aller plus loin&lt;br /&gt;
*# Coder un algorithme de traitement d&#039;image simple (e.g, un filtrage médian, ou un algo qui transporte les couleurs d&#039;une photo vers une autre photo)&lt;br /&gt;
&lt;br /&gt;
* Liens pour démarrer&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Traitement_d%27images Wikipedia]]&lt;br /&gt;
** [[http://www.ipol.im/ Image Processing on line]] (permet de tester en ligne des algorithmes sur vos images)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Nim et la théorie des jeux impartiaux ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur: Pierre Hyvernat&lt;br /&gt;
&lt;br /&gt;
* Le jeu de Nim (aussi appelé jeu des allumettes) est l&#039;un des premiers jeux ayant été analysé mathématiquement (par Charles Bouton en 1901). Les stratégies gagnantes peuvent être calculées en utilisant le développement en base 2 des nombres, et l&#039;opération d&#039;&amp;quot;addition de Nim&amp;quot; (XOR). La théorie de ce type de jeux (jeux &amp;quot;impartiaux&amp;quot;) est assez simple, mais de nombreuses instances de jeux sont encore non résolues.&lt;br /&gt;
* Objectifs:&lt;br /&gt;
*# comprendre la théorie du jeu de Nim (et la programmer)&lt;br /&gt;
*# comprendre le théorème de Sprague Grundy qui montre que tout jeu impartial est équivalent à un jeu de nim&lt;br /&gt;
*# regarder quelques autres exemples de tels jeux : jeu de Nim déguisés, ou jeux véritablement différents&lt;br /&gt;
*# programmer une version naịve de recherche de stratégie basée sur le théorème de Sprague-Grundy pour quelques jeux&lt;br /&gt;
&lt;br /&gt;
* Liens pour commencer&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Jeux_de_Nim jeu de Nim]]&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_de_Sprague-Grundy théorème de Sprague Grundy]]&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Jeu_de_Grundy jeu de Grundy]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== La suite de Conway et la classification périodique des &amp;quot;éléments&amp;quot; ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur : Pierre Hyvernat&lt;br /&gt;
* La suite de Conway est la suite suivante : 1 ; 11 ; 21 ; 1211 ; 111221 ; ... Chaque terme est obtenu en &amp;quot;lisant&amp;quot; le terme précédent.                                                                                                                                                            &lt;br /&gt;
** &amp;quot;1&amp;quot; : un &amp;quot;1&amp;quot; -&amp;gt; 11&lt;br /&gt;
** &amp;quot;11&amp;quot; : deux &amp;quot;1&amp;quot; -&amp;gt; 21&lt;br /&gt;
** &amp;quot;21&amp;quot; : un &amp;quot;2&amp;quot;, un &amp;quot;1&amp;quot; -&amp;gt; 1211&lt;br /&gt;
** &amp;quot;1211&amp;quot; : un &amp;quot;1&amp;quot;, un &amp;quot;2&amp;quot;, deux &amp;quot;1&amp;quot; -&amp;gt; 111221&lt;br /&gt;
** etc.&lt;br /&gt;
Cette suite possède des propriétés étonantes données par le théorème &amp;quot;chimique&amp;quot;, le théorème &amp;quot;arithmétique&amp;quot; et le théorème &amp;quot;cosmologique&amp;quot;.&lt;br /&gt;
* Objectifs :                                                                                                                                                                                                                  &lt;br /&gt;
*# comprendre les énoncés de ces théorèmes, et l&#039;idée de la preuve du premier.                    &lt;br /&gt;
*# programmer la suite de Conway pour retrouver la classification des &amp;quot;atomes&amp;quot;&lt;br /&gt;
*# écrire un programme pour calculer expérimentalement une approximation de la constante &amp;quot;lambda&amp;quot; ainsi que des fréquences respectives des différents atomes.&lt;br /&gt;
*# écrire un programme pour calculer la suite de Robinson, une variante plus simple de la suite de Conway&lt;br /&gt;
&lt;br /&gt;
* Liens pour commencer&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Suite_de_Conway suite de Conway]]&lt;br /&gt;
** [[https://fr.wikipedia.org/wiki/Suite_de_Robinson suite de Robinson]]&lt;br /&gt;
&lt;br /&gt;
== Initiation à la démonstration sur ordinateur et certification de logiciel ==&lt;br /&gt;
&lt;br /&gt;
* Tuteur: Tom Hirschowitz&lt;br /&gt;
* Résumé: &lt;br /&gt;
* Objectifs: &lt;br /&gt;
*# prendre en main le logiciel [[https://coq.inria.fr Coq]] de démonstration sur ordinateur,&lt;br /&gt;
*# programmer certaines démonstrations basiques en Coq,&lt;br /&gt;
*# suivre le début du cours [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]],&lt;br /&gt;
* Pour aller plus loin : Software Foundations est un cours assez long et très bien fait, il y aura suffisamment à faire. Eventuellement, selon l&#039;intérêt de l&#039;étudiant, étude des fondements mathématiques de Coq.&lt;br /&gt;
* Liens pour démarrer&lt;br /&gt;
** [[https://www.cis.upenn.edu/~bcpierce/sf Software Foundations]]&lt;br /&gt;
** [[https://coq.inria.fr Coq]]&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5333</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5333"/>
		<updated>2011-10-19T14:07:57Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= Seminars =&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
= Readings =&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
===C*-algebras associated with lambda-synchronizing subshifts and flow equivalence=== &lt;br /&gt;
Kengo Matsumoto. [http://arxiv.org/abs/1105.3250 Link].&lt;br /&gt;
&lt;br /&gt;
This is the paper we started with. It was probably a bit early to attack, and Tim quickly switched the focus to earlier, more accessible papers.&lt;br /&gt;
&lt;br /&gt;
===Cuntz-Krieger algebras of directed graphs=== &lt;br /&gt;
Kumjian, Pask, and Raeburn. Pacific J. Math. 184 (1998), 161–174. [http://www.uow.edu.au/~dpask/index_files/papers/ckaodg.pdf Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The authors specify, via a universal property, a C*-algebra associated to any given directed graph satisfying a condition called &#039;&#039;row finiteness&#039;&#039; (all vertices have finite input degree). &lt;br /&gt;
The idea is that the C*-algebra is a subalgebra of the algebra of bounded operators on an infinite-dimensional Hilbert space. A natural construction, starting from any infinite-dimensional Hilbert space, starts by choosing a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{v \in V} H&amp;lt;/math&amp;gt;. That is, we specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all vertices of the given graph. Then, for each &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;, choose now a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{t(e) = v} H&amp;lt;/math&amp;gt;. That is, specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all input edges of &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Then, each vertex &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt; is interpreted as being the projection to the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component of the direct sum. Each edge is interpreted&lt;br /&gt;
as a &#039;&#039;partial isometry&#039;&#039;. That means an operator &amp;lt;math&amp;gt;u&amp;lt;/math&amp;gt; such that both &amp;lt;math&amp;gt;u u^*&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;u^* u&amp;lt;/math&amp;gt; are projections. For an edge &amp;lt;math&amp;gt;e \colon v \to v&#039;&amp;lt;/math&amp;gt;, &lt;br /&gt;
we pick the partial isometry projecting on the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component, and then injecting into the &amp;lt;math&amp;gt;e&amp;lt;/math&amp;gt;th component of the &amp;lt;math&amp;gt;v&#039;&amp;lt;/math&amp;gt;th component.&lt;br /&gt;
&lt;br /&gt;
We then take the smallest subalgebra generated by these projections and partial isometries, to obtain the universal C*-algebra satisfying the specified property.&lt;br /&gt;
&lt;br /&gt;
===A family of 2-graphs arising from two-dimensional subshifts=== &lt;br /&gt;
Pask, Raeburn, and Weaver. Ergodic Theory and Dynamical Systems, to appear.  [http://arxiv.org/abs/0804.3447 Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the same vein as the previous paper, but starting from a more complicated notion of dynamics than just directed graphs. Here, the considered systems are based on a rather restricted class of labellings of the discrete plane. Acceptable labellings are determined by a local constraint, to be satisfied by all occurrences of a basic tile in the plane. Such labellings are viewed as the infinite path space of a dynamical system, I&#039;m not so sure what the states are exactly now. But the essential idea is that providing a path from an occurrence v of the basic tile to another, say v&#039;, roughly consists in labelling the points between v and v&#039;, respecting the local constraint. &lt;br /&gt;
&lt;br /&gt;
We stopped reading this in depth, because there is a hypothesis ensuring that in the direction orthogonal to &amp;lt;math&amp;gt;y = x&amp;lt;/math&amp;gt;, labellings always extend in a deterministic way. In a sense, this makes the dynamics 1-dimensional. Guillaume argued that this is a very restricted class of dynamical systems.&lt;br /&gt;
&lt;br /&gt;
===Graphs, groupoids, and Cuntz-Krieger algebras=== &lt;br /&gt;
Kumjian, Pask, Raeburn, and Renault. J. Funct. Anal. 144 (1997), 505–541. [http://www.uow.edu.au/~dpask/index_files/papers/ggcka.pdf Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We briefly had a look at this paper for getting an idea of the groupoid-based approach to constructing C*-algebras associated to dynamical systems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and sheaves ==&lt;br /&gt;
&lt;br /&gt;
===Topos theory and complex analysis=== &lt;br /&gt;
Christiane Rousseau. [http://www.springerlink.com/content/n23286006t0x2685/ Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math&amp;gt;.&lt;br /&gt;
By adequately quotienting &amp;lt;math&amp;gt;\mathbb{N} \times \mathbb{N}&amp;lt;/math&amp;gt;, we get an object &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt; of rationals, which similarly maps any object to (the usual) &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt;.&lt;br /&gt;
There are then at least two natural ways of defining an object of real numbers: as limits of Cauchy sequences, or as Dedekind cuts.&lt;br /&gt;
In case the site is spatial, i.e., is the poset of open sets of a space &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, Dedekind cuts nicely yield the sheaf of continuous maps to &amp;lt;math&amp;gt;\mathbb{R}&amp;lt;/math&amp;gt;. &lt;br /&gt;
Anyway, from such an object of real numbers, one may construct an object of complex numbers. Rousseau actually axiomatises such an object, and proceeds to perform a few constructions of analysis.&lt;br /&gt;
&lt;br /&gt;
What might be of interest to us is that the object of complex numbers bears a striking resemblance to C*-algebras. &lt;br /&gt;
To start with, the object of complex numbers is a complete metric space object, as well as a ring object. &lt;br /&gt;
In particular, if the underlying space is compact, then its global sections are precisely the elements of the classical C*-algebra of continuous maps &amp;lt;math&amp;gt;X \to \mathbb{C}&amp;lt;/math&amp;gt;. Furthermore, the internal ring operations agree with the C*-algebra&#039;s. And, although Thomas would certainly recall better than me, a Cauchy sequence converges for the usual norm iff it converges for the internal norm (hence in the internal language).&lt;br /&gt;
&lt;br /&gt;
In the general case, continuous maps to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt; do not form a C*-algebra, and one usually resorts to some compactification procedure. This is not necessary in the sheaf-theoretic approach: the norm of an internal complex number is a continuous map to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt;, i.e., pointwise norm.&lt;br /&gt;
&lt;br /&gt;
== Dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
===Cellular automata and groups=== &lt;br /&gt;
T. Ceccherini-Silberstein and M. Coornaert. Springer, 2010. [http://www-irma.u-strasbg.fr/~coornaer/livres.html Link].&lt;br /&gt;
&lt;br /&gt;
Guillaume referred to this book in his talk, notably for concepts such as entropy, surjunctivity, and amenability.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5332</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5332"/>
		<updated>2011-10-19T14:07:23Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= Seminars =&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
= Readings =&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras associated with lambda-synchronizing subshifts and flow equivalence === &lt;br /&gt;
&lt;br /&gt;
Kengo Matsumoto. [http://arxiv.org/abs/1105.3250 Link].&lt;br /&gt;
&lt;br /&gt;
This is the paper we started with. It was probably a bit early to attack, and Tim quickly switched the focus to earlier, more accessible papers.&lt;br /&gt;
&lt;br /&gt;
===Cuntz-Krieger algebras of directed graphs=== Kumjian, Pask, and Raeburn. Pacific J. Math. 184 (1998), 161–174. [http://www.uow.edu.au/~dpask/index_files/papers/ckaodg.pdf Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The authors specify, via a universal property, a C*-algebra associated to any given directed graph satisfying a condition called &#039;&#039;row finiteness&#039;&#039; (all vertices have finite input degree). &lt;br /&gt;
The idea is that the C*-algebra is a subalgebra of the algebra of bounded operators on an infinite-dimensional Hilbert space. A natural construction, starting from any infinite-dimensional Hilbert space, starts by choosing a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{v \in V} H&amp;lt;/math&amp;gt;. That is, we specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all vertices of the given graph. Then, for each &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;, choose now a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{t(e) = v} H&amp;lt;/math&amp;gt;. That is, specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all input edges of &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Then, each vertex &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt; is interpreted as being the projection to the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component of the direct sum. Each edge is interpreted&lt;br /&gt;
as a &#039;&#039;partial isometry&#039;&#039;. That means an operator &amp;lt;math&amp;gt;u&amp;lt;/math&amp;gt; such that both &amp;lt;math&amp;gt;u u^*&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;u^* u&amp;lt;/math&amp;gt; are projections. For an edge &amp;lt;math&amp;gt;e \colon v \to v&#039;&amp;lt;/math&amp;gt;, &lt;br /&gt;
we pick the partial isometry projecting on the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component, and then injecting into the &amp;lt;math&amp;gt;e&amp;lt;/math&amp;gt;th component of the &amp;lt;math&amp;gt;v&#039;&amp;lt;/math&amp;gt;th component.&lt;br /&gt;
&lt;br /&gt;
We then take the smallest subalgebra generated by these projections and partial isometries, to obtain the universal C*-algebra satisfying the specified property.&lt;br /&gt;
&lt;br /&gt;
===A family of 2-graphs arising from two-dimensional subshifts=== Pask, Raeburn, and Weaver. Ergodic Theory and Dynamical Systems, to appear.  [http://arxiv.org/abs/0804.3447 Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the same vein as the previous paper, but starting from a more complicated notion of dynamics than just directed graphs. Here, the considered systems are based on a rather restricted class of labellings of the discrete plane. Acceptable labellings are determined by a local constraint, to be satisfied by all occurrences of a basic tile in the plane. Such labellings are viewed as the infinite path space of a dynamical system, I&#039;m not so sure what the states are exactly now. But the essential idea is that providing a path from an occurrence v of the basic tile to another, say v&#039;, roughly consists in labelling the points between v and v&#039;, respecting the local constraint. &lt;br /&gt;
&lt;br /&gt;
We stopped reading this in depth, because there is a hypothesis ensuring that in the direction orthogonal to &amp;lt;math&amp;gt;y = x&amp;lt;/math&amp;gt;, labellings always extend in a deterministic way. In a sense, this makes the dynamics 1-dimensional. Guillaume argued that this is a very restricted class of dynamical systems.&lt;br /&gt;
&lt;br /&gt;
===Graphs, groupoids, and Cuntz-Krieger algebras=== Kumjian, Pask, Raeburn, and Renault. J. Funct. Anal. 144 (1997), 505–541. [http://www.uow.edu.au/~dpask/index_files/papers/ggcka.pdf Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We briefly had a look at this paper for getting an idea of the groupoid-based approach to constructing C*-algebras associated to dynamical systems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and sheaves ==&lt;br /&gt;
&lt;br /&gt;
===Topos theory and complex analysis=== Christiane Rousseau. [http://www.springerlink.com/content/n23286006t0x2685/ Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math&amp;gt;.&lt;br /&gt;
By adequately quotienting &amp;lt;math&amp;gt;\mathbb{N} \times \mathbb{N}&amp;lt;/math&amp;gt;, we get an object &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt; of rationals, which similarly maps any object to (the usual) &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt;.&lt;br /&gt;
There are then at least two natural ways of defining an object of real numbers: as limits of Cauchy sequences, or as Dedekind cuts.&lt;br /&gt;
In case the site is spatial, i.e., is the poset of open sets of a space &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, Dedekind cuts nicely yield the sheaf of continuous maps to &amp;lt;math&amp;gt;\mathbb{R}&amp;lt;/math&amp;gt;. &lt;br /&gt;
Anyway, from such an object of real numbers, one may construct an object of complex numbers. Rousseau actually axiomatises such an object, and proceeds to perform a few constructions of analysis.&lt;br /&gt;
&lt;br /&gt;
What might be of interest to us is that the object of complex numbers bears a striking resemblance to C*-algebras. &lt;br /&gt;
To start with, the object of complex numbers is a complete metric space object, as well as a ring object. &lt;br /&gt;
In particular, if the underlying space is compact, then its global sections are precisely the elements of the classical C*-algebra of continuous maps &amp;lt;math&amp;gt;X \to \mathbb{C}&amp;lt;/math&amp;gt;. Furthermore, the internal ring operations agree with the C*-algebra&#039;s. And, although Thomas would certainly recall better than me, a Cauchy sequence converges for the usual norm iff it converges for the internal norm (hence in the internal language).&lt;br /&gt;
&lt;br /&gt;
In the general case, continuous maps to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt; do not form a C*-algebra, and one usually resorts to some compactification procedure. This is not necessary in the sheaf-theoretic approach: the norm of an internal complex number is a continuous map to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt;, i.e., pointwise norm.&lt;br /&gt;
&lt;br /&gt;
== Dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
===Cellular automata and groups=== T. Ceccherini-Silberstein and M. Coornaert. Springer, 2010. [http://www-irma.u-strasbg.fr/~coornaer/livres.html Link].&lt;br /&gt;
&lt;br /&gt;
Guillaume referred to this book in his talk, notably for concepts such as entropy, surjunctivity, and amenability.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5331</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5331"/>
		<updated>2011-10-19T14:07:03Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= Seminars =&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
= Readings =&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras associated with lambda-synchronizing subshifts and flow equivalence === Kengo Matsumoto. [http://arxiv.org/abs/1105.3250 Link].&lt;br /&gt;
&lt;br /&gt;
This is the paper we started with. It was probably a bit early to attack, and Tim quickly switched the focus to earlier, more accessible papers.&lt;br /&gt;
&lt;br /&gt;
===Cuntz-Krieger algebras of directed graphs=== Kumjian, Pask, and Raeburn. Pacific J. Math. 184 (1998), 161–174. [http://www.uow.edu.au/~dpask/index_files/papers/ckaodg.pdf Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The authors specify, via a universal property, a C*-algebra associated to any given directed graph satisfying a condition called &#039;&#039;row finiteness&#039;&#039; (all vertices have finite input degree). &lt;br /&gt;
The idea is that the C*-algebra is a subalgebra of the algebra of bounded operators on an infinite-dimensional Hilbert space. A natural construction, starting from any infinite-dimensional Hilbert space, starts by choosing a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{v \in V} H&amp;lt;/math&amp;gt;. That is, we specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all vertices of the given graph. Then, for each &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;, choose now a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{t(e) = v} H&amp;lt;/math&amp;gt;. That is, specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all input edges of &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Then, each vertex &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt; is interpreted as being the projection to the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component of the direct sum. Each edge is interpreted&lt;br /&gt;
as a &#039;&#039;partial isometry&#039;&#039;. That means an operator &amp;lt;math&amp;gt;u&amp;lt;/math&amp;gt; such that both &amp;lt;math&amp;gt;u u^*&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;u^* u&amp;lt;/math&amp;gt; are projections. For an edge &amp;lt;math&amp;gt;e \colon v \to v&#039;&amp;lt;/math&amp;gt;, &lt;br /&gt;
we pick the partial isometry projecting on the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component, and then injecting into the &amp;lt;math&amp;gt;e&amp;lt;/math&amp;gt;th component of the &amp;lt;math&amp;gt;v&#039;&amp;lt;/math&amp;gt;th component.&lt;br /&gt;
&lt;br /&gt;
We then take the smallest subalgebra generated by these projections and partial isometries, to obtain the universal C*-algebra satisfying the specified property.&lt;br /&gt;
&lt;br /&gt;
===A family of 2-graphs arising from two-dimensional subshifts=== Pask, Raeburn, and Weaver. Ergodic Theory and Dynamical Systems, to appear.  [http://arxiv.org/abs/0804.3447 Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the same vein as the previous paper, but starting from a more complicated notion of dynamics than just directed graphs. Here, the considered systems are based on a rather restricted class of labellings of the discrete plane. Acceptable labellings are determined by a local constraint, to be satisfied by all occurrences of a basic tile in the plane. Such labellings are viewed as the infinite path space of a dynamical system, I&#039;m not so sure what the states are exactly now. But the essential idea is that providing a path from an occurrence v of the basic tile to another, say v&#039;, roughly consists in labelling the points between v and v&#039;, respecting the local constraint. &lt;br /&gt;
&lt;br /&gt;
We stopped reading this in depth, because there is a hypothesis ensuring that in the direction orthogonal to &amp;lt;math&amp;gt;y = x&amp;lt;/math&amp;gt;, labellings always extend in a deterministic way. In a sense, this makes the dynamics 1-dimensional. Guillaume argued that this is a very restricted class of dynamical systems.&lt;br /&gt;
&lt;br /&gt;
===Graphs, groupoids, and Cuntz-Krieger algebras=== Kumjian, Pask, Raeburn, and Renault. J. Funct. Anal. 144 (1997), 505–541. [http://www.uow.edu.au/~dpask/index_files/papers/ggcka.pdf Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We briefly had a look at this paper for getting an idea of the groupoid-based approach to constructing C*-algebras associated to dynamical systems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and sheaves ==&lt;br /&gt;
&lt;br /&gt;
===Topos theory and complex analysis=== Christiane Rousseau. [http://www.springerlink.com/content/n23286006t0x2685/ Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math&amp;gt;.&lt;br /&gt;
By adequately quotienting &amp;lt;math&amp;gt;\mathbb{N} \times \mathbb{N}&amp;lt;/math&amp;gt;, we get an object &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt; of rationals, which similarly maps any object to (the usual) &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt;.&lt;br /&gt;
There are then at least two natural ways of defining an object of real numbers: as limits of Cauchy sequences, or as Dedekind cuts.&lt;br /&gt;
In case the site is spatial, i.e., is the poset of open sets of a space &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, Dedekind cuts nicely yield the sheaf of continuous maps to &amp;lt;math&amp;gt;\mathbb{R}&amp;lt;/math&amp;gt;. &lt;br /&gt;
Anyway, from such an object of real numbers, one may construct an object of complex numbers. Rousseau actually axiomatises such an object, and proceeds to perform a few constructions of analysis.&lt;br /&gt;
&lt;br /&gt;
What might be of interest to us is that the object of complex numbers bears a striking resemblance to C*-algebras. &lt;br /&gt;
To start with, the object of complex numbers is a complete metric space object, as well as a ring object. &lt;br /&gt;
In particular, if the underlying space is compact, then its global sections are precisely the elements of the classical C*-algebra of continuous maps &amp;lt;math&amp;gt;X \to \mathbb{C}&amp;lt;/math&amp;gt;. Furthermore, the internal ring operations agree with the C*-algebra&#039;s. And, although Thomas would certainly recall better than me, a Cauchy sequence converges for the usual norm iff it converges for the internal norm (hence in the internal language).&lt;br /&gt;
&lt;br /&gt;
In the general case, continuous maps to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt; do not form a C*-algebra, and one usually resorts to some compactification procedure. This is not necessary in the sheaf-theoretic approach: the norm of an internal complex number is a continuous map to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt;, i.e., pointwise norm.&lt;br /&gt;
&lt;br /&gt;
== Dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
===Cellular automata and groups=== T. Ceccherini-Silberstein and M. Coornaert. Springer, 2010. [http://www-irma.u-strasbg.fr/~coornaer/livres.html Link].&lt;br /&gt;
&lt;br /&gt;
Guillaume referred to this book in his talk, notably for concepts such as entropy, surjunctivity, and amenability.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5330</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5330"/>
		<updated>2011-10-19T14:06:41Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= Seminars =&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
= Readings =&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
===C*-algebras associated with lambda-synchronizing subshifts and flow equivalence=== Kengo Matsumoto. [http://arxiv.org/abs/1105.3250 Link].&lt;br /&gt;
&lt;br /&gt;
This is the paper we started with. It was probably a bit early to attack, and Tim quickly switched the focus to earlier, more accessible papers.&lt;br /&gt;
&lt;br /&gt;
===Cuntz-Krieger algebras of directed graphs=== Kumjian, Pask, and Raeburn. Pacific J. Math. 184 (1998), 161–174. [http://www.uow.edu.au/~dpask/index_files/papers/ckaodg.pdf Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The authors specify, via a universal property, a C*-algebra associated to any given directed graph satisfying a condition called &#039;&#039;row finiteness&#039;&#039; (all vertices have finite input degree). &lt;br /&gt;
The idea is that the C*-algebra is a subalgebra of the algebra of bounded operators on an infinite-dimensional Hilbert space. A natural construction, starting from any infinite-dimensional Hilbert space, starts by choosing a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{v \in V} H&amp;lt;/math&amp;gt;. That is, we specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all vertices of the given graph. Then, for each &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;, choose now a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{t(e) = v} H&amp;lt;/math&amp;gt;. That is, specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all input edges of &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Then, each vertex &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt; is interpreted as being the projection to the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component of the direct sum. Each edge is interpreted&lt;br /&gt;
as a &#039;&#039;partial isometry&#039;&#039;. That means an operator &amp;lt;math&amp;gt;u&amp;lt;/math&amp;gt; such that both &amp;lt;math&amp;gt;u u^*&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;u^* u&amp;lt;/math&amp;gt; are projections. For an edge &amp;lt;math&amp;gt;e \colon v \to v&#039;&amp;lt;/math&amp;gt;, &lt;br /&gt;
we pick the partial isometry projecting on the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component, and then injecting into the &amp;lt;math&amp;gt;e&amp;lt;/math&amp;gt;th component of the &amp;lt;math&amp;gt;v&#039;&amp;lt;/math&amp;gt;th component.&lt;br /&gt;
&lt;br /&gt;
We then take the smallest subalgebra generated by these projections and partial isometries, to obtain the universal C*-algebra satisfying the specified property.&lt;br /&gt;
&lt;br /&gt;
===A family of 2-graphs arising from two-dimensional subshifts=== Pask, Raeburn, and Weaver. Ergodic Theory and Dynamical Systems, to appear.  [http://arxiv.org/abs/0804.3447 Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In the same vein as the previous paper, but starting from a more complicated notion of dynamics than just directed graphs. Here, the considered systems are based on a rather restricted class of labellings of the discrete plane. Acceptable labellings are determined by a local constraint, to be satisfied by all occurrences of a basic tile in the plane. Such labellings are viewed as the infinite path space of a dynamical system, I&#039;m not so sure what the states are exactly now. But the essential idea is that providing a path from an occurrence v of the basic tile to another, say v&#039;, roughly consists in labelling the points between v and v&#039;, respecting the local constraint. &lt;br /&gt;
&lt;br /&gt;
We stopped reading this in depth, because there is a hypothesis ensuring that in the direction orthogonal to &amp;lt;math&amp;gt;y = x&amp;lt;/math&amp;gt;, labellings always extend in a deterministic way. In a sense, this makes the dynamics 1-dimensional. Guillaume argued that this is a very restricted class of dynamical systems.&lt;br /&gt;
&lt;br /&gt;
===Graphs, groupoids, and Cuntz-Krieger algebras=== Kumjian, Pask, Raeburn, and Renault. J. Funct. Anal. 144 (1997), 505–541. [http://www.uow.edu.au/~dpask/index_files/papers/ggcka.pdf Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We briefly had a look at this paper for getting an idea of the groupoid-based approach to constructing C*-algebras associated to dynamical systems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and sheaves ==&lt;br /&gt;
&lt;br /&gt;
===Topos theory and complex analysis=== Christiane Rousseau. [http://www.springerlink.com/content/n23286006t0x2685/ Link].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math&amp;gt;.&lt;br /&gt;
By adequately quotienting &amp;lt;math&amp;gt;\mathbb{N} \times \mathbb{N}&amp;lt;/math&amp;gt;, we get an object &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt; of rationals, which similarly maps any object to (the usual) &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt;.&lt;br /&gt;
There are then at least two natural ways of defining an object of real numbers: as limits of Cauchy sequences, or as Dedekind cuts.&lt;br /&gt;
In case the site is spatial, i.e., is the poset of open sets of a space &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, Dedekind cuts nicely yield the sheaf of continuous maps to &amp;lt;math&amp;gt;\mathbb{R}&amp;lt;/math&amp;gt;. &lt;br /&gt;
Anyway, from such an object of real numbers, one may construct an object of complex numbers. Rousseau actually axiomatises such an object, and proceeds to perform a few constructions of analysis.&lt;br /&gt;
&lt;br /&gt;
What might be of interest to us is that the object of complex numbers bears a striking resemblance to C*-algebras. &lt;br /&gt;
To start with, the object of complex numbers is a complete metric space object, as well as a ring object. &lt;br /&gt;
In particular, if the underlying space is compact, then its global sections are precisely the elements of the classical C*-algebra of continuous maps &amp;lt;math&amp;gt;X \to \mathbb{C}&amp;lt;/math&amp;gt;. Furthermore, the internal ring operations agree with the C*-algebra&#039;s. And, although Thomas would certainly recall better than me, a Cauchy sequence converges for the usual norm iff it converges for the internal norm (hence in the internal language).&lt;br /&gt;
&lt;br /&gt;
In the general case, continuous maps to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt; do not form a C*-algebra, and one usually resorts to some compactification procedure. This is not necessary in the sheaf-theoretic approach: the norm of an internal complex number is a continuous map to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt;, i.e., pointwise norm.&lt;br /&gt;
&lt;br /&gt;
== Dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
===Cellular automata and groups=== T. Ceccherini-Silberstein and M. Coornaert. Springer, 2010. [http://www-irma.u-strasbg.fr/~coornaer/livres.html Link].&lt;br /&gt;
&lt;br /&gt;
Guillaume referred to this book in his talk, notably for concepts such as entropy, surjunctivity, and amenability.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5329</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5329"/>
		<updated>2011-10-19T14:03:41Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= Seminars =&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
= Readings =&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
#[http://arxiv.org/abs/1105.3250 C*-algebras associated with lambda-synchronizing subshifts and flow equivalence], by Kengo Matsumoto.&lt;br /&gt;
This is the paper we started with. It was probably a bit early to attack, and Tim quickly switched the focus to earlier, more accessible papers.&lt;br /&gt;
&lt;br /&gt;
#[http://www.uow.edu.au/~dpask/index_files/papers/ckaodg.pdf Cuntz-Krieger algebras of directed graphs], by Kumjian, Pask, and Raeburn. Pacific J. Math. 184 (1998), 161–174.&lt;br /&gt;
&lt;br /&gt;
The authors specify, via a universal property, a C*-algebra associated to any given directed graph satisfying a condition called &#039;&#039;row finiteness&#039;&#039; (all vertices have finite input degree). &lt;br /&gt;
The idea is that the C*-algebra is a subalgebra of the algebra of bounded operators on an infinite-dimensional Hilbert space. A natural construction, starting from any infinite-dimensional Hilbert space, starts by choosing a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{v \in V} H&amp;lt;/math&amp;gt;. That is, we specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all vertices of the given graph. Then, for each &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;, choose now a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{t(e) = v} H&amp;lt;/math&amp;gt;. That is, specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all input edges of &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Then, each vertex &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt; is interpreted as being the projection to the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component of the direct sum. Each edge is interpreted&lt;br /&gt;
as a &#039;&#039;partial isometry&#039;&#039;. That means an operator &amp;lt;math&amp;gt;u&amp;lt;/math&amp;gt; such that both &amp;lt;math&amp;gt;u u^*&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;u^* u&amp;lt;/math&amp;gt; are projections. For an edge &amp;lt;math&amp;gt;e \colon v \to v&#039;&amp;lt;/math&amp;gt;, &lt;br /&gt;
we pick the partial isometry projecting on the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component, and then injecting into the &amp;lt;math&amp;gt;e&amp;lt;/math&amp;gt;th component of the &amp;lt;math&amp;gt;v&#039;&amp;lt;/math&amp;gt;th component.&lt;br /&gt;
&lt;br /&gt;
We then take the smallest subalgebra generated by these projections and partial isometries, to obtain the universal C*-algebra satisfying the specified property.&lt;br /&gt;
&lt;br /&gt;
#[http://arxiv.org/abs/0804.3447 A family of 2-graphs arising from two-dimensional subshifts], by Pask, Raeburn, and Weaver. Ergodic Theory and Dynamical Systems, to appear. &lt;br /&gt;
&lt;br /&gt;
In the same vein as the previous paper, but starting from a more complicated notion of dynamics than just directed graphs. Here, the considered systems are based on a rather restricted class of labellings of the discrete plane. Acceptable labellings are determined by a local constraint, to be satisfied by all occurrences of a basic tile in the plane. Such labellings are viewed as the infinite path space of a dynamical system, I&#039;m not so sure what the states are exactly now. But the essential idea is that providing a path from an occurrence v of the basic tile to another, say v&#039;, roughly consists in labelling the points between v and v&#039;, respecting the local constraint. &lt;br /&gt;
&lt;br /&gt;
We stopped reading this in depth, because there is a hypothesis ensuring that in the direction orthogonal to &amp;lt;math&amp;gt;y = x&amp;lt;/math&amp;gt;, labellings always extend in a deterministic way. In a sense, this makes the dynamics 1-dimensional. Guillaume argued that this is a very restricted class of dynamical systems.&lt;br /&gt;
&lt;br /&gt;
#[http://www.uow.edu.au/~dpask/index_files/papers/ggcka.pdf Graphs, groupoids, and Cuntz-Krieger algebras], by Kumjian, Pask, Raeburn, and Renault. J. Funct. Anal. 144 (1997), 505–541.&lt;br /&gt;
&lt;br /&gt;
We briefly had a look at this paper for getting an idea of the groupoid-based approach to constructing C*-algebras associated to dynamical systems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and sheaves ==&lt;br /&gt;
&lt;br /&gt;
#[http://www.springerlink.com/content/n23286006t0x2685/ Topos theory and complex analysis], by Christiane Rousseau.&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math&amp;gt;.&lt;br /&gt;
By adequately quotienting &amp;lt;math&amp;gt;\mathbb{N} \times \mathbb{N}&amp;lt;/math&amp;gt;, we get an object &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt; of rationals, which similarly maps any object to (the usual) &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt;.&lt;br /&gt;
There are then at least two natural ways of defining an object of real numbers: as limits of Cauchy sequences, or as Dedekind cuts.&lt;br /&gt;
In case the site is spatial, i.e., is the poset of open sets of a space &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, Dedekind cuts nicely yield the sheaf of continuous maps to &amp;lt;math&amp;gt;\mathbb{R}&amp;lt;/math&amp;gt;. &lt;br /&gt;
Anyway, from such an object of real numbers, one may construct an object of complex numbers. Rousseau actually axiomatises such an object, and proceeds to perform a few constructions of analysis.&lt;br /&gt;
&lt;br /&gt;
What might be of interest to us is that the object of complex numbers bears a striking resemblance to C*-algebras. &lt;br /&gt;
To start with, the object of complex numbers is a complete metric space object, as well as a ring object. &lt;br /&gt;
In particular, if the underlying space is compact, then its global sections are precisely the elements of the classical C*-algebra of continuous maps &amp;lt;math&amp;gt;X \to \mathbb{C}&amp;lt;/math&amp;gt;. Furthermore, the internal ring operations agree with the C*-algebra&#039;s. And, although Thomas would certainly recall better than me, a Cauchy sequence converges for the usual norm iff it converges for the internal norm (hence in the internal language).&lt;br /&gt;
&lt;br /&gt;
In the general case, continuous maps to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt; do not form a C*-algebra, and one usually resorts to some compactification procedure. This is not necessary in the sheaf-theoretic approach: the norm of an internal complex number is a continuous map to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt;, i.e., pointwise norm.&lt;br /&gt;
&lt;br /&gt;
== Dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
#[http://www-irma.u-strasbg.fr/~coornaer/livres.html Cellular automata and groups], by T. Ceccherini-Silberstein and M. Coornaert. Springer, 2010.&lt;br /&gt;
Guillaume referred to this book in his talk, notably for concepts such as entropy, surjunctivity, and amenability.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5328</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5328"/>
		<updated>2011-10-19T13:57:56Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= Seminars =&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
= Readings =&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://arxiv.org/abs/1105.3250 C*-algebras associated with lambda-synchronizing subshifts and flow equivalence]&#039;&#039;&#039;, by Kengo Matsumoto.&lt;br /&gt;
This is the paper we started with. It was probably a bit early to attack, and Tim quickly switched the focus to earlier, more accessible papers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.uow.edu.au/~dpask/index_files/papers/ckaodg.pdf Cuntz-Krieger algebras of directed graphs]&#039;&#039;&#039;, by Kumjian, Pask, and Raeburn. Pacific J. Math. 184 (1998), 161–174.&lt;br /&gt;
&lt;br /&gt;
The authors specify, via a universal property, a C*-algebra associated to any given directed graph satisfying a condition called &#039;&#039;row finiteness&#039;&#039; (all vertices have finite input degree). &lt;br /&gt;
The idea is that the C*-algebra is a subalgebra of the algebra of bounded operators on an infinite-dimensional Hilbert space. A natural construction, starting from any infinite-dimensional Hilbert space, starts by choosing a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{v \in V} H&amp;lt;/math&amp;gt;. That is, we specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all vertices of the given graph. Then, for each &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;, choose now a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{t(e) = v} H&amp;lt;/math&amp;gt;. That is, specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all input edges of &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Then, each vertex &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt; is interpreted as being the projection to the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component of the direct sum. Each edge is interpreted&lt;br /&gt;
as a &#039;&#039;partial isometry&#039;&#039;. That means an operator &amp;lt;math&amp;gt;u&amp;lt;/math&amp;gt; such that both &amp;lt;math&amp;gt;u u^*&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;u^* u&amp;lt;/math&amp;gt; are projections. For an edge &amp;lt;math&amp;gt;e \colon v \to v&#039;&amp;lt;/math&amp;gt;, &lt;br /&gt;
we pick the partial isometry projecting on the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component, and then injecting into the &amp;lt;math&amp;gt;e&amp;lt;/math&amp;gt;th component of the &amp;lt;math&amp;gt;v&#039;&amp;lt;/math&amp;gt;th component.&lt;br /&gt;
&lt;br /&gt;
We then take the smallest subalgebra generated by these projections and partial isometries, to obtain the universal C*-algebra satisfying the specified property.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://arxiv.org/abs/0804.3447 A family of 2-graphs arising from two-dimensional subshifts]&#039;&#039;&#039;, by Pask, Raeburn, and Weaver. Ergodic Theory and Dynamical Systems, to appear. &lt;br /&gt;
&lt;br /&gt;
In the same vein as the previous paper, but starting from a more complicated notion of dynamics than just directed graphs. Here, the considered systems are based on a rather restricted class of labellings of the discrete plane. Acceptable labellings are determined by a local constraint, to be satisfied by all occurrences of a basic tile in the plane. Such labellings are viewed as the infinite path space of a dynamical system, I&#039;m not so sure what the states are exactly now. But the essential idea is that providing a path from an occurrence v of the basic tile to another, say v&#039;, roughly consists in labelling the points between v and v&#039;, respecting the local constraint. &lt;br /&gt;
&lt;br /&gt;
We stopped reading this in depth, because there is a hypothesis ensuring that in the direction orthogonal to &amp;lt;math&amp;gt;y = x&amp;lt;/math&amp;gt;, labellings always extend in a deterministic way. In a sense, this makes the dynamics 1-dimensional. Guillaume argued that this is a very restricted class of dynamical systems.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.uow.edu.au/~dpask/index_files/papers/ggcka.pdf Graphs, groupoids, and Cuntz-Krieger algebras]&#039;&#039;&#039;, by Kumjian, Pask, Raeburn, and Renault. J. Funct. Anal. 144 (1997), 505–541.&lt;br /&gt;
&lt;br /&gt;
We briefly had a look at this paper for getting an idea of the groupoid-based approach to constructing C*-algebras associated to dynamical systems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and sheaves ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.springerlink.com/content/n23286006t0x2685/ Topos theory and complex analysis]&#039;&#039;&#039;, by Christiane Rousseau.&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math&amp;gt;.&lt;br /&gt;
By adequately quotienting &amp;lt;math&amp;gt;\mathbb{N} \times \mathbb{N}&amp;lt;/math&amp;gt;, we get an object &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt; of rationals, which similarly maps any object to (the usual) &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt;.&lt;br /&gt;
There are then at least two natural ways of defining an object of real numbers: as limits of Cauchy sequences, or as Dedekind cuts.&lt;br /&gt;
In case the site is spatial, i.e., is the poset of open sets of a space &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, Dedekind cuts nicely yield the sheaf of continuous maps to &amp;lt;math&amp;gt;\mathbb{R}&amp;lt;/math&amp;gt;. &lt;br /&gt;
Anyway, from such an object of real numbers, one may construct an object of complex numbers. Rousseau actually axiomatises such an object, and proceeds to perform a few constructions of analysis.&lt;br /&gt;
&lt;br /&gt;
What might be of interest to us is that the object of complex numbers bears a striking resemblance to C*-algebras. &lt;br /&gt;
To start with, the object of complex numbers is a complete metric space object, as well as a ring object. &lt;br /&gt;
In particular, if the underlying space is compact, then its global sections are precisely the elements of the classical C*-algebra of continuous maps &amp;lt;math&amp;gt;X \to \mathbb{C}&amp;lt;/math&amp;gt;. Furthermore, the internal ring operations agree with the C*-algebra&#039;s. And, although Thomas would certainly recall better than me, a Cauchy sequence converges for the usual norm iff it converges for the internal norm (hence in the internal language).&lt;br /&gt;
&lt;br /&gt;
In the general case, continuous maps to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt; do not form a C*-algebra, and one usually resorts to some compactification procedure. This is not necessary in the sheaf-theoretic approach: the norm of an internal complex number is a continuous map to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt;, i.e., pointwise norm.&lt;br /&gt;
&lt;br /&gt;
== Dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www-irma.u-strasbg.fr/~coornaer/livres.html Cellular automata and groups]&#039;&#039;&#039;, by T. Ceccherini-Silberstein and M. Coornaert. Springer, 2010.&lt;br /&gt;
Guillaume referred to this book in his talk, notably for concepts such as entropy, surjunctivity, and amenability.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5327</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5327"/>
		<updated>2011-10-19T13:54:05Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= Seminars =&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
= Readings =&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and dynamical systems ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://arxiv.org/abs/1105.3250 C*-algebras associated with lambda-synchronizing subshifts and flow equivalence]&#039;&#039;&#039;, by Kengo Matsumoto.&lt;br /&gt;
This is the paper we started with. It was probably a bit early to attack, and Tim quickly switched the focus to earlier, more accessible papers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.uow.edu.au/~dpask/index_files/papers/ckaodg.pdf Cuntz-Krieger algebras of directed graphs]&#039;&#039;&#039;, by Kumjian, Pask, and Raeburn. Pacific J. Math. 184 (1998), 161–174.&lt;br /&gt;
&lt;br /&gt;
The authors specify, via a universal property, a C*-algebra associated to any given directed graph satisfying a condition called &#039;&#039;row finiteness&#039;&#039; (all vertices have finite input degree). &lt;br /&gt;
The idea is that the C*-algebra is a subalgebra of the algebra of bounded operators on an infinite-dimensional Hilbert space. A natural construction, starting from any infinite-dimensional Hilbert space, starts by choosing a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{v \in V} H&amp;lt;/math&amp;gt;. That is, we specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all vertices of the given graph. Then, for each &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;, choose now a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{t(e) = v} H&amp;lt;/math&amp;gt;. That is, specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all input edges of &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Then, each vertex &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt; is interpreted as being the projection to the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component of the direct sum. Each edge is interpreted&lt;br /&gt;
as a &#039;&#039;partial isometry&#039;&#039;. That means an operator &amp;lt;math&amp;gt;u&amp;lt;/math&amp;gt; such that both &amp;lt;math&amp;gt;u u^*&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;u^* u&amp;lt;/math&amp;gt; are projections. For an edge &amp;lt;math&amp;gt;e \colon v \to v&#039;&amp;lt;/math&amp;gt;, &lt;br /&gt;
we pick the partial isometry projecting on the &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;th component, and then injecting into the &amp;lt;math&amp;gt;e&amp;lt;/math&amp;gt;th component of the &amp;lt;math&amp;gt;v&#039;&amp;lt;/math&amp;gt;th component.&lt;br /&gt;
&lt;br /&gt;
We then take the smallest subalgebra generated by these projections and partial isometries, to obtain the universal C*-algebra satisfying the specified property.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://arxiv.org/abs/0804.3447 A family of 2-graphs arising from two-dimensional subshifts]&#039;&#039;&#039;, by Pask, Raeburn, and Weaver. Ergodic Theory and Dynamical Systems, to appear. &lt;br /&gt;
&lt;br /&gt;
In the same vein as the previous paper, but starting from a more complicated notion of dynamics than just directed graphs. Here, the considered systems are based on a rather restricted class of labellings of the discrete plane. Acceptable labellings are determined by a local constraint, to be satisfied by all occurrences of a basic tile in the plane. Such labellings are viewed as the infinite path space of a dynamical system, I&#039;m not so sure what the states are exactly now. But the essential idea is that providing a path from an occurrence v of the basic tile to another, say v&#039;, roughly consists in labelling the points between v and v&#039;, respecting the local constraint. &lt;br /&gt;
&lt;br /&gt;
We stopped reading this in depth, because there is a hypothesis ensuring that in the direction orthogonal to &amp;lt;math&amp;gt;y = x&amp;lt;/math&amp;gt;, labellings always extend in a deterministic way. In a sense, this makes the dynamics 1-dimensional. Guillaume argued that this is a very restricted class of dynamical systems.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.uow.edu.au/~dpask/index_files/papers/ggcka.pdf Graphs, groupoids, and Cuntz-Krieger algebras]&#039;&#039;&#039;, by Kumjian, Pask, Raeburn, and Renault. J. Funct. Anal. 144 (1997), 505–541.&lt;br /&gt;
&lt;br /&gt;
== C*-algebras and sheaves ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.springerlink.com/content/n23286006t0x2685/ Topos theory and complex analysis]&#039;&#039;&#039;, by Christiane Rousseau.&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math&amp;gt;.&lt;br /&gt;
By adequately quotienting &amp;lt;math&amp;gt;\mathbb{N} \times \mathbb{N}&amp;lt;/math&amp;gt;, we get an object &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt; of rationals, which similarly maps any object to (the usual) &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt;.&lt;br /&gt;
There are then at least two natural ways of defining an object of real numbers: as limits of Cauchy sequences, or as Dedekind cuts.&lt;br /&gt;
In case the site is spatial, i.e., is the poset of open sets of a space &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, Dedekind cuts nicely yield the sheaf of continuous maps to &amp;lt;math&amp;gt;\mathbb{R}&amp;lt;/math&amp;gt;. &lt;br /&gt;
Anyway, from such an object of real numbers, one may construct an object of complex numbers. Rousseau actually axiomatises such an object, and proceeds to perform a few constructions of analysis.&lt;br /&gt;
&lt;br /&gt;
What might be of interest to us is that the object of complex numbers bears a striking resemblance to C*-algebras. &lt;br /&gt;
To start with, the object of complex numbers is a complete metric space object, as well as a ring object. &lt;br /&gt;
In particular, if the underlying space is compact, then its global sections are precisely the elements of the classical C*-algebra of continuous maps &amp;lt;math&amp;gt;X \to \mathbb{C}&amp;lt;/math&amp;gt;. Furthermore, the internal ring operations agree with the C*-algebra&#039;s. And, although Thomas would certainly recall better than me, a Cauchy sequence converges for the usual norm iff it converges for the internal norm (hence in the internal language).&lt;br /&gt;
&lt;br /&gt;
In the general case, continuous maps to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt; do not form a C*-algebra, and one usually resorts to some compactification procedure. This is not necessary in the sheaf-theoretic approach: the norm of an internal complex number is a continuous map to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt;, i.e., pointwise norm.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5326</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5326"/>
		<updated>2011-10-19T13:33:45Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
== Seminars ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
== Readings ==&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and dynamical systems ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://arxiv.org/abs/1105.3250 C*-algebras associated with lambda-synchronizing subshifts and flow equivalence]&#039;&#039;&#039;, by Kengo Matsumoto.&lt;br /&gt;
This is the paper we started with. It was probably a bit early to attack, and Tim quickly switched the focus to earlier, more accessible papers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.uow.edu.au/~dpask/index_files/papers/ckaodg.pdf Cuntz-Krieger algebras of directed graphs]&#039;&#039;&#039;, by Kumjian, Pask, and Raeburn. Pacific J. Math. 184 (1998), 161–174.&lt;br /&gt;
&lt;br /&gt;
The authors specify, via a universal property, a C*-algebra associated to any given directed graph satisfying a condition called &#039;&#039;row finiteness&#039;&#039; (all vertices have finite input degree). &lt;br /&gt;
The idea is that the C*-algebra is a subalgebra of the algebra of bounded operators on an infinite-dimensional Hilbert space. A natural construction, starting from any infinite-dimensional Hilbert space, starts by choosing a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{v \in V} H&amp;lt;/math&amp;gt;. That is, we specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all vertices of the given graph. Then, for each &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;, choose now a specific isomorphism &amp;lt;math&amp;gt;H \cong \bigoplus_{t(e) = v} H&amp;lt;/math&amp;gt;. That is, specify a way of seeing &amp;lt;math&amp;gt;H&amp;lt;/math&amp;gt; as a direct sum of itself over all input edges of &amp;lt;math&amp;gt;v&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and categories ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.springerlink.com/content/n23286006t0x2685/ Topos theory and complex analysis]&#039;&#039;&#039;, by Christiane Rousseau.&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math&amp;gt;.&lt;br /&gt;
By adequately quotienting &amp;lt;math&amp;gt;\mathbb{N} \times \mathbb{N}&amp;lt;/math&amp;gt;, we get an object &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt; of rationals, which similarly maps any object to (the usual) &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt;.&lt;br /&gt;
There are then at least two natural ways of defining an object of real numbers: as limits of Cauchy sequences, or as Dedekind cuts.&lt;br /&gt;
In case the site is spatial, i.e., is the poset of open sets of a space &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, Dedekind cuts nicely yield the sheaf of continuous maps to &amp;lt;math&amp;gt;\mathbb{R}&amp;lt;/math&amp;gt;. &lt;br /&gt;
Anyway, from such an object of real numbers, one may construct an object of complex numbers. Rousseau actually axiomatises such an object, and proceeds to perform a few constructions of analysis.&lt;br /&gt;
&lt;br /&gt;
What might be of interest to us is that the object of complex numbers bears a striking resemblance to C*-algebras. &lt;br /&gt;
To start with, the object of complex numbers is a complete metric space object, as well as a ring object. &lt;br /&gt;
In particular, if the underlying space is compact, then its global sections are precisely the elements of the classical C*-algebra of continuous maps &amp;lt;math&amp;gt;X \to \mathbb{C}&amp;lt;/math&amp;gt;. Furthermore, the internal ring operations agree with the C*-algebra&#039;s. And, although Thomas would certainly recall better than me, a Cauchy sequence converges for the usual norm iff it converges for the internal norm (hence in the internal language).&lt;br /&gt;
&lt;br /&gt;
In the general case, continuous maps to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt; do not form a C*-algebra, and one usually resorts to some compactification procedure. This is not necessary in the sheaf-theoretic approach: the norm of an internal complex number is a continuous map to &amp;lt;math&amp;gt;\mathbb{C}&amp;lt;/math&amp;gt;, i.e., pointwise norm.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5325</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5325"/>
		<updated>2011-10-19T13:12:07Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
== Seminars ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
== Readings ==&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and dynamical systems ===&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and categories ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.springerlink.com/content/n23286006t0x2685/ Topos theory and complex analysis]&#039;&#039;&#039;, by Christiane Rousseau.&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math&amp;gt;.&lt;br /&gt;
By adequately quotienting &amp;lt;math&amp;gt;\mathbb{N} \times \mathbb{N}&amp;lt;/math&amp;gt;, we get an object &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt; of rationals, which similarly maps any object to (the usual) &amp;lt;math&amp;gt;\mathbb{Q}&amp;lt;/math&amp;gt;.&lt;br /&gt;
There are then at least two natural ways of defining an object of real numbers: as limits of Cauchy sequences, or as Dedekind cuts.&lt;br /&gt;
In case the site is spatial, i.e., is the poset of open sets of a space &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, Dedekind cuts nicely yield the sheaf of continuous maps to &amp;lt;math&amp;gt;\mathbb{R}&amp;lt;/math&amp;gt;. &lt;br /&gt;
Anyway, from such an object of real numbers, one may construct an object of complex numbers. Rousseau actually axiomatises such an object, and proceeds to perform a few constructions of analysis.&lt;br /&gt;
&lt;br /&gt;
What might be of interest to us is that the object of complex numbers bears a striking resemblance to C*-algebras. In particular, if the underlying space is compact, then its global sections are precisely the elements of the classical C*-algebra of continuous maps &amp;lt;math&amp;gt;X \to \mathbb{C}&amp;lt;/math&amp;gt;. Furthermore,&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5324</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5324"/>
		<updated>2011-10-19T13:03:11Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
== Seminars ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
== Readings ==&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and dynamical systems ===&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and categories ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.springerlink.com/content/n23286006t0x2685/ Topos theory and complex analysis]&#039;&#039;&#039;, by Christiane Rousseau.&lt;br /&gt;
&lt;br /&gt;
In any sheaf topos, there is a natural numbers object, given by the constant sheaf mapping any object of the underlying site to &amp;lt;math&amp;gt;\mathbb{N}&amp;lt;/math.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=CatDyn&amp;diff=5323</id>
		<title>CatDyn</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=CatDyn&amp;diff=5323"/>
		<updated>2011-10-19T13:01:05Z</updated>

		<summary type="html">&lt;p&gt;Thirs : a déplacé CatDyn vers Infinity-categories, symbolic dynamical systems, and mathematical physics: Je savais pas que c&amp;#039;était forcément le titre affiché en haut de la page.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#REDIRECT [[Infinity-categories, symbolic dynamical systems, and mathematical physics]]&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5322</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5322"/>
		<updated>2011-10-19T13:01:05Z</updated>

		<summary type="html">&lt;p&gt;Thirs : a déplacé CatDyn vers Infinity-categories, symbolic dynamical systems, and mathematical physics: Je savais pas que c&amp;#039;était forcément le titre affiché en haut de la page.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Infinity-categories, symbolic dynamical systems, and mathematical physics ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
== Seminars ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
== Readings ==&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and dynamical systems ===&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and categories ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.springerlink.com/content/n23286006t0x2685/ Link to the paper at Springer&#039;s]Topos theory and complex analysis&#039;&#039;&#039;, by Christiane Rousseau.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5321</id>
		<title>Infinity-categories, symbolic dynamical systems, and mathematical physics</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Infinity-categories,_symbolic_dynamical_systems,_and_mathematical_physics&amp;diff=5321"/>
		<updated>2011-10-19T12:59:09Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Infinity-categories, symbolic dynamical systems, and mathematical physics ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This is a page to keep track of our working groups and readings related to the project &#039;&#039;Infinity-categories, symbolic dynamics, and mathematical physics&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
== Seminars ==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Oct 6, 2011&#039;&#039;&#039; Thomas Seiller. Introduction to C*-algebras.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sept 29, 2011&#039;&#039;&#039; Guillaume Theyssier talked about some aspects of symbolic dynamics that might benefit from a categorical approach.&lt;br /&gt;
&lt;br /&gt;
== Readings ==&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and dynamical systems ===&lt;br /&gt;
&lt;br /&gt;
=== C*-algebras and categories ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;[http://www.springerlink.com/content/n23286006t0x2685/ Link to the paper at Springer&#039;s]Topos theory and complex analysis&#039;&#039;&#039;, by Christiane Rousseau.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5090</id>
		<title>ANR PML</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5090"/>
		<updated>2011-01-13T11:34:25Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Context and positioning of the proposal */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;URL of PML project: &amp;lt;tt&amp;gt;http://lama.univ-savoie.fr/tracpml&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Context and positioning of the proposal==&lt;br /&gt;
&lt;br /&gt;
Ever since FORTRAN appeared fifty years ago, programming languages have been evolving rapidly. These languages now include more and more sophisticated concepts like &amp;quot;objects&amp;quot;, &amp;quot;type inference&amp;quot;, &amp;quot;modules&amp;quot;... However, this richness is also what makes it more and more complex to train programmers and makes it difficult for them to keep up with the innovations and changes in programming languages.&lt;br /&gt;
&lt;br /&gt;
Another orthogonal phenomenon is the emergence of formal methods used in conjunction with various programming languages to test, check or prove software. This introduces another layer to languages in order to write specifications, and sometimes yet another one for proofs. Learning a programming language together with the associated specification/proof languages can take an important effort.&lt;br /&gt;
&lt;br /&gt;
Projects such as [http://www.cs.utexas.edu/users/moore/acl2/ ACL2], the successor of  [http://www.cs.utexas.edu/users/boyer/ftp/nqthm the Boyer-Moore theorem prover] uses a rather simple language (namely LISP) both as a programming language and specification language, allowing to keep a unity in the system. Unfortunately, LISP is somewhat limited both as a programming language (no good treatment of sum types, no module system) and a specification language (very limited quantification). Moreover, LISP has no compile-time type-checking, which has proved very useful to detect bugs and automatically assert properties.&lt;br /&gt;
&lt;br /&gt;
The aim of the present project is to build a very powerful language (with no loss of expressive power compared to state of the art languages) based on a very small number of simple features. We think this will be possible thanks to recent progress both in the semantics of programming languages and the apparition of new algorithms for type inference based on constraint-solving. In fact, we propose in [RAF10b] an innovative concept derived from the later to enable this: constraint-checking.&lt;br /&gt;
&lt;br /&gt;
Moreover, the language will be used not only as a programming language and a specification language (like in ACL2), but also as the proof language. This is natural for an ML-like language because pattern-matching is a natural and powerful way to make a proof by case analysis. This also means that our tool will consist of relatively few (unified) features, yet powerful.&lt;br /&gt;
&lt;br /&gt;
The idea of a new language arose from the discovery of a new typing algorithm [RAF10b] whose implementation gave birth to a first implementation of PML (Proved ML) by Christophe Raffalli. This implementation is already available from [http://www.lama.univ-savoie.fr/~pml the web page of the language]. However, turning PML into a real tool requires a lot of research and implementation work and this is why we request the help of the ANR. Some of the goals are highlighted in the next sections.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML approach to mathematics and program certification is unique&#039;&#039;&#039; Existing provers or certification tools feature a base programming language, and a logical layer on top of it (be it to write mathematical statements, specifications, or proofs). PML is very different in spirit: every statement, including sophisticated mathematical ones, is reduced to a statement asserting that a program fragment does not raise any error. &lt;br /&gt;
&lt;br /&gt;
PML has no dedicated proof language, but the user can still write proofs! Existing programming languages supporting specifications use one or more of the following two alternatives: automated proofs (ACL2, Why) or proof obligations, that the user can prove using a specific language (Coq extraction, Focalize, Why). Several systems provide both possibilities, manual proofs being used only when automation fails. PML is again very different: it introduces a new instruction, written with a &amp;quot;scissors symbol&amp;quot; &amp;lt;tt&amp;gt;&#039;&#039;&#039;8&amp;lt;&#039;&#039;&#039;&amp;lt;/tt&amp;gt; to express that the corresponding position in the program is &#039;&#039;dead&#039;&#039;, meaning that it can not be reached during evaluation. This condition is checked by a terminating variant of the Knuth-Bendix completion algorithm. This is rather simple and therefore easier to trust than modern decision procedures. However, it only solves trivial cases: to write complex proofs, the user just uses the same syntax as for programs to do case analysis or induction (i.e., recursive definitions). This means that the user does not need learn a specific proof language and hopefully implies that PML is easier to learn and probably more adapted to industry that previous solutions.&lt;br /&gt;
&lt;br /&gt;
The logic of PML is just the equational theory of its programming language; and we use variants of Knuth-Bendix completion as a proof-checker. The first experiments with the current implementation are promising. However, adapting the Knuth-Bendix procedure to the context of ML is a complex and new research problem. A lot more work is needed, for instance to handle proofs in arithmetic which occur quite often. Here is an example of a proof in arithmetic, checked in the current version of PML. This is not completely satisfactory (hard to write), but shows the use of the language for both proofs and programs and the use of recursive functions for inductive proofs:&lt;br /&gt;
&lt;br /&gt;
  val rec mul_associative x y z |- (x * y) * z == x * (y * z)&lt;br /&gt;
    proof match x with&lt;br /&gt;
      Z[] -&amp;gt; 8&amp;lt; (* trivial case handled automatically by Knuth-Bendix *)&lt;br /&gt;
&lt;br /&gt;
    | S[x&#039;] -&amp;gt;&lt;br /&gt;
      let _ = mul_associative x&#039; y z in (* There is a syntactic sugar for that... *)&lt;br /&gt;
        (* this adds the fact that (x&#039;*y) * z == x&#039; * (y*z) to the environment *)&lt;br /&gt;
 &lt;br /&gt;
      let _ = mul_right_distributive y (x&#039; * y) z in&lt;br /&gt;
        (* this adds the fact that (y + x&#039;*y) * z == y*z + (x&#039;*y)*z *)&lt;br /&gt;
 &lt;br /&gt;
        (* the environment now contains enough information for Knuth Bendix to handle the rest:&lt;br /&gt;
         *    - x*(y*z)  ==  y*z + x&#039;*(y*z)  : by definition&lt;br /&gt;
         *    - x*y == y + x&#039;*y : by definition&lt;br /&gt;
         *      and so (x*y)*z == (y + x&#039;*z)*z&lt;br /&gt;
         *    - (x&#039;*y) * z == x&#039; * (y*z)  :  by the recursive call to mul_associative&lt;br /&gt;
         *    - (y + x&#039;*y) * z == y*z + (x&#039;*y)*z : by the call to mul_right_distributive  *)&lt;br /&gt;
      8&amp;lt;&lt;br /&gt;
&lt;br /&gt;
Moreover, this style of proof is declarative and relatively readable (like Mizar proofs) while concise at the same time. This is very important when you want to maintain large developments.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;PML is different from the other modern programming languages&#039;&#039;&#039; because its design focuses on a few powerful concepts. One consequence is that it is more difficult for a compiler to produce efficient code. In particular, since PML unifies several notions of products (modules, tuples and records), there is no simple way to choose the internal representation of a product, especially with implicit subtyping. Writing a good compiler for PML will thus require more complex and original optimization schemes (probably driven by typing) than for languages like OCaml or Haskell. A Polish student (Wojciech Matyjewicz) is just starting a PhD on this very topic.&lt;br /&gt;
&lt;br /&gt;
Here is a simple example, accepted by the current version of PML, demonstrating product types, sum types and subtyping. We define ternary trees as an extension of binary trees with an implicit subtyping&lt;br /&gt;
relation (all functions accepting binary_trees will accept ternary trees, by ignoring the &amp;lt;tt&amp;gt;middle_son&amp;lt;/tt&amp;gt;):&lt;br /&gt;
&lt;br /&gt;
 type rec binary_tree (A) =&lt;br /&gt;
   [ Nil[] | Node[A with left_son : binary_tree(A); right_son : binary_tree(A)] ; ]&lt;br /&gt;
 type rec ternary_tree(A) =&lt;br /&gt;
   binary_tree({ A with middle_son : ternary_tree(A) ;})&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML requires a termination criterion&#039;&#039;&#039; because a proof by induction will just be a normal recursive program. Such a program has to be well-founded in order to correspond to a valid proof. A subset of Haskell can now use the Aprove tool to establish termination for simple programs. However, we want the test to be fully integrated with the language, and be compatible with very modular programs. At the moment, these goals seem difficult to achieve with Aprove or other external termination checkers. A first termination criterion based on Lee, Jones &amp;amp; Ben-Amram&#039;s &amp;quot;size-change termination principle&amp;quot; was implemented by Pierre Hyvernat [Hyv10b]. While this test is quite powerful, it is necessarily incomplete, and quite some work is required to make termination proofs of complex programs tractable.&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical description==&lt;br /&gt;
&lt;br /&gt;
===Background, state of the art===&lt;br /&gt;
&lt;br /&gt;
====Programming language====&lt;br /&gt;
&lt;br /&gt;
The ML programming language, created by Robin Milner &amp;lt;em&amp;gt;et al&amp;lt;/em&amp;gt; in the 80&#039;s has two major distinctive features:&lt;br /&gt;
* Algebraic data-types and pattern matching: data types are basically all constructed using fixpoint, Cartesian product (product types) and disjoint union (sum types).&lt;br /&gt;
* Static type inference: the type of every piece of code is automatically inferred using Hindley-Milner algorithm (HM). By construction, once compiled, an ML program can not crash (no segmentation fault). More precisely, when we do not use unsafe features of the language (like interface with unsafe libraries written in C), if an ML program produces a segmentation fault, then there is a bug in the type-checker or the compiler.&lt;br /&gt;
&lt;br /&gt;
Recent progress in type inference algorithm uses constraint solving. This means that the type system can be described in first-order predicate logic in such a way that a type inference problem is a formula written in a decidable fragment of first-order predicate logic (often the purely existential fragment). Hence, any constraint solver can be turned into a type-checker for ML. These approach is known as HM(X) (see [SOW97]).&lt;br /&gt;
&lt;br /&gt;
There are two problems with this approach:&lt;br /&gt;
* The complexity of constraint solving can be too high for practical use, especially when using a general purpose constraint solver. To our knowledge, there are currently no mainstream implementation of ML based on HM(X).&lt;br /&gt;
* HM(X) does not completely solve the problem of subtyping. The language to express the types constructed by the constraint solver is the same as the language of types used by programmers. With constraints &amp;lt;math&amp;gt;\alpha \subseteq \beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\alpha \subseteq \gamma&amp;lt;/math&amp;gt; for three types &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\gamma&amp;lt;/math&amp;gt;, the most natural solution is &amp;lt;math&amp;gt;\alpha = \beta \cap \gamma&amp;lt;/math&amp;gt;. This implies that intersection needs to be part of the language for types. This means that constraints such as &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \delta&amp;lt;/math&amp;gt; may also appear and they are problematic to deal with. Similar reasoning shows that constraints of the form &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \beta&#039; \cup \gamma&#039;&amp;lt;/math&amp;gt; may appear, increasing the complexity of constraint solving by an exponential factor.&lt;br /&gt;
&lt;br /&gt;
PML&#039;s approach is to replace type-inference by &#039;&#039;constraint &amp;lt;u&amp;gt;checking&amp;lt;/u&amp;gt;&#039;&#039; rather than constraint solving: we only check that the constraints are satisfiable in some model. Type-checking in the current implementation of PML can be seen as a black box ensuring that nothing can go wrong during execution. Moreover, since we do not need to write solutions for the constraints, the language for types can be relatively simple. In fact, the types written by the programmer aren&#039;t even the actual type constraints that are checked: they are syntactic sugar for the partial identity on the intended type (giving for free nice feature like higher-order parametric types, that is types with parameters which may be themselves types with parameters). In other words, the expression &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; is a synonym for &amp;lt;tt&amp;gt;(id_nat x)&amp;lt;/tt&amp;gt; where&lt;br /&gt;
  val rec id_nat x = match x with&lt;br /&gt;
      Z[] -&amp;gt; Z[]&lt;br /&gt;
    | S[x&#039;] -&amp;gt; S[id_nat x&#039;]&lt;br /&gt;
is defined internally by PML. The constraints generated by &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; mean exactly that &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is of type &amp;lt;tt&amp;gt;nat&amp;lt;/tt&amp;gt;...&lt;br /&gt;
&lt;br /&gt;
With this approach, we loose type-inference and the ability to display types in error messages. Nevertheless, PML error reporting is quite helpful because, in case of problems, it displays three positions in the code and an error message like this &amp;lt;tt&amp;gt;error at position 1, label &amp;quot;id&amp;quot; projected at position 2 do not appear in the value constructed at position 3&amp;lt;/tt&amp;gt;. This kind of error message is in fact of bounded length and often more useful than OCaml or SML messages. We can understand this as showing three points in the &#039;&#039;slice&#039;&#039; of the error, as introduced by Joe Wells in [HW04].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Proof assistant====&lt;br /&gt;
&lt;br /&gt;
Proof assistants have evolved rapidly since Automath in the 70th. Two main trends coexist: automated proof assistants such as ACL2, PVS and &#039;&#039;safe&#039;&#039; ones such as Coq, Isabelle, PhoX, Lego, HOL, Matita, &amp;lt;em&amp;gt;etc.&amp;lt;/em&amp;gt; The former incorporate very sophisticated automated deduction strategies, with no &#039;&#039;certificate&#039;&#039; for the validity of the proof, while the later require all proofs to be done in a specific framework (like natural deduction or type theory) allowing for a simple check of the proof. The gap between the two approaches tend to be reduced by the emergence of complex tactics (for Coq or Isabelle mainly) which build proofs for the user. For instance Zenon is an advanced automated first-order theorem prover that outputs a Coq proof.&lt;br /&gt;
&lt;br /&gt;
The common defect of all these proof assistants is that a proof can not be written nor understood without running the proof assistant. Some proof assistants such as Mizar or Alf do not follow exactly the above scheme: Mizar has a declarative style for proof which is (in theory) readable by a human and checked by a limited checker (This proof style has been adapted to Coq and Isabelle). Unfortunately, there is no formal description of the Mizar proof checker. Alf on the other hand is based on proof theory and requires the user to basically write the complete proof tree just leaving out a few details. The logic is very well formalized and simple, but writing proof is tedious and not similar to the usual practice of informal mathematics.&lt;br /&gt;
&lt;br /&gt;
This picture of the world of proof assistants shows that some fundamental work is needed. In the current version of PML, the logic is just an equational theory of the underlying programming language. This is easily described formally. The proof engine is, like in Mizar, a limited automated checker inspired by the Knuth-Bendix completion algorithm (KB). The completion algorithm used in PML had to be adapted to the higher-order constructs of ML-like languages and restricted to ensure termination and an acceptable complexity. The current limitation is probably too strong: it is limited to closed terms and cannot use universal theorems automatically (as in the first example of section 1, where one has to give explicitly the argument to use distributivity).&lt;br /&gt;
&lt;br /&gt;
Nevertheless, preliminary examples in the current version shows that the approach is worth trying: proofs are concise and readable once you know the language. A very encouraging point is that all examples where written without interface. This really means that proofs are readable without the help of a computer.&lt;br /&gt;
&lt;br /&gt;
===Rationale highlighting the originality and novelty of the proposal===&lt;br /&gt;
&lt;br /&gt;
The final objective of our project would be a full PML compiler, bootstrapped and completely proved with itself (full bootstrap). This does not exist for any language and is far too ambitious for a four years project.  More realistically, we plan to produce a compiler for PML, written in PML, but not proved in PML yet.&lt;br /&gt;
&lt;br /&gt;
We also want to develop proof-checking in such a way as to allow very elegant proofs, supporting the feasibility of a full bootstrap by various examples, some of them being near to industrial application, some others being algorithms coming from implementation of programming languages.&lt;br /&gt;
&lt;br /&gt;
We have focused the existing development on the quality of the language both for proofs and programs. By quality, we mean easy to understand and write (and therefore, easy to learn). We think that using the programming language as a proof language could make formal methods more attractive to the industry without the defect of systems like PVS and ACL2 where the automated tactics replace the need for a proof language, but are sometimes hard to control and use. For instance, finding the right &#039;&#039;lemmas&#039;&#039; to make a proof possible in ACL2 is quite difficult.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other proof systems devoted to programming.&#039;&#039;&#039; Many other proof systems have been used or specifically developed&lt;br /&gt;
to allow the production of certified code: extraction in Coq, Why with its automated prover Who from the Proval project, Focalize, PVS, ATS, ... None of these system uses the programming language as a proof language. They all have a dedicated language for proofs and even if some of them like Focalize or Coq extraction using a Mizar style mode for proof, have readable proofs, learning the proof language is never trivial. Other systems like PVS, ATS, Why using Who rely on automated deduction. In those cases, the behavior of the automated prover is always hard to predict.&lt;br /&gt;
&lt;br /&gt;
Another selling point is that the logic and programming language are fully integrated. This is not a two level systems like most systems (but not all, ACL2 for instance is fully integrated). In PML, the statements of theorems and their proofs are expressions at the same level than programs. This means that a program can contain specifications that contains themselves program definitions in their statement or proof and so on. This is generally not possible (even in ACL2) and makes it possible to write modules with their specifications.&lt;br /&gt;
&lt;br /&gt;
One of the key idea for this project is that any ML-like programming language has all the features needed for a proof language: case analysis via pattern matching and exception handling, induction, calling previously defined program/theorems. This means that it is natural to explore this direction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other programming languages&#039;&#039;&#039;. Another key idea in PML is to develop the language and its proof-checker together. This has a great impact on the design of PML. Let&#039;s illustrate this with a concrete example: exception handling. In ML, there is a construct&lt;br /&gt;
  try P with e -&amp;gt; R&lt;br /&gt;
but, this is not sufficient to do case analysis on the fact that a program &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises or not an exception. In particular, &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; can be the proof just in case &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises an exception. However there is no place holder for the normal case (without exception). This is why we had to introduce a&lt;br /&gt;
  let try x = P in Q with e -&amp;gt; R&lt;br /&gt;
where &amp;lt;tt&amp;gt;Q&amp;lt;/tt&amp;gt; is evaluated only when &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; reduces to a value.&lt;br /&gt;
&lt;br /&gt;
A great number of decisions on the language design comes from the interaction between the development of the programming language and its proof-checker. Another key feature of PML, which makes the project original even as a programming language compared to many other projects of programming language research (GALLIUM, Haskell, Scala, ...) is the use of constraint checking. This choice arises from the fact that we want a language as small as possible, because a proof-checker is complex and therefore, we want to fully unify all sorts of Cartesian product including modules, records, tuples and variant with multiple argument. This is already achieved in the current implementation of PML and to my knowledge, no ML like language have a unique but still powerful notion of Cartesian product.&lt;br /&gt;
&lt;br /&gt;
All the systems previously mentioned allow to prove programs in limited subsets of existing languages like ML or Haskell. The prover has to find ways to deal with those languages&#039; defects rather than improve them...&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical program, project management==&lt;br /&gt;
&lt;br /&gt;
===Specific aims of the proposal===&lt;br /&gt;
&lt;br /&gt;
As said in the previous section, the final objective would be to have a fully bootstrapped PML language: this would mean that PML is entirely written and proved in PML. This would be too ambitious at first, and we chose to focus here on the design of the language plus a proof of concept, that is compilation and proof of various examples, searching to do our best on the following points:&lt;br /&gt;
&lt;br /&gt;
* Natural way of writing programs (Task 1)&lt;br /&gt;
* Efficiency of the code generated by the compiler, despite the heavily use of subtyping (Task 3)&lt;br /&gt;
* Readable and short proofs (Task 1, Task 4)&lt;br /&gt;
* Efficiency of type-checking and compilation (Task 2 and 6)&lt;br /&gt;
* Efficiency of proof-checking (Task 4 and 6)&lt;br /&gt;
* All of the above points need testing, and we created a transverse fifth task for that.&lt;br /&gt;
&lt;br /&gt;
===Project management===&lt;br /&gt;
&lt;br /&gt;
We plan to have one 3 days workshop per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems. We already have the agreement of some people to participate in such meetings: Joe Wells, Assia Mahbouby, Andreas Abel, ...&lt;br /&gt;
We plan to have one 3 days meetings per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems.&lt;br /&gt;
&lt;br /&gt;
We will also organize two project meetings per year, just to keep track of progress, share idea and organize the above workshops and other invitations.&lt;br /&gt;
&lt;br /&gt;
We want also to organize visits of one or two members of the project to visit researchers on similar topic (typically a member of the project could visit one of the invited speaker of our workshop). Members of the project should also travel to conference on the subject like POPL, LICS, CSL, TYPES or the recently created CPP (first conference in 2011).&lt;br /&gt;
&lt;br /&gt;
===Detailed description of the work organized by tasks===&lt;br /&gt;
&lt;br /&gt;
====Task 1 - theoretical work, design of the language ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Alexandre Miquel, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.a - Correctness of the constraint checking algorithm&#039;&#039;&#039; (delivered&lt;br /&gt;
09/2012): [RAF10b] already cover the correctness without polymorphism. A draft version of &lt;br /&gt;
the correctness proof with polymorphism does exist but needs more work. The &lt;br /&gt;
main open problem here is the interaction with the termination-check. The current work &lt;br /&gt;
proves that when constraints are checked, the program can only loop via recursive definitions.&lt;br /&gt;
Then, we would like to prove that the program is terminating if recursive definitions are accepted by the &lt;br /&gt;
termination checker. However, this is non trivial.&lt;br /&gt;
&lt;br /&gt;
This being a central piece of PML, it should be also one&lt;br /&gt;
of the first tests for PML in task 5. We could also prove this part of PML in&lt;br /&gt;
Coq (in fact 2 provers proving themselves and each other correct is a much&lt;br /&gt;
stronger warranty than one prover proving itself).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.b - Consistency of proof-checking&#039;&#039;&#039; (beginning 09/2011, delivered before 09/2013 for the core of the language): This is essential for clearly defining the logic of PML and prove its consistency. This should not be too hard for the core of the language. However, this proof has to be extended to take into account all future extensions of the language and could be seen as a &#039;&#039;permanent task&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.c - Adaptation of uniqueness typing to the context of constraint checking&#039;&#039;&#039; (beginning 09/2012, delivered 01/2014): The current version of PML is a pure functional programming language, with no imperative feature. This is problematic, because input/output is necessary for real programs and affectations are required for efficiency especially when using large arrays. We plan to adapt the approach of the [http://clean.cs.ru.nl/ Clean language] [AGR92], [AcP95], [AcP97], [VPA07]. In Clean, all programs can be analyzed as purely functional programs, but the type system can check that some data are not used any more and reuse the place in memory for other data (allowing affectation). For instance, in such a context writing in a file &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; can be written as &amp;lt;tt&amp;gt;let f&#039; = write f str in ...&amp;lt;/tt&amp;gt;, but the compiler must check that &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; will not be used anymore implying the equivalence between the standard imperative semantics of writing to file and the purely functional semantics used by proofs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.d - Private, abstract and existential types.&#039;&#039;&#039; (beginning 09/2011, delivered&lt;br /&gt;
09/2012 for private type, beginning 09/2012, delivered&lt;br /&gt;
09/2013 for existential types and beginning 09/2013, delivered 09/2015 for abstract&lt;br /&gt;
types)&lt;br /&gt;
 &lt;br /&gt;
Abstract data types hide the definition of a data type and allow the user of&lt;br /&gt;
a library to be sure that his code will continue to work even if the internal&lt;br /&gt;
representation of data are changed. In the context of constraint-checking in&lt;br /&gt;
PML, adding abstract data types seems to be a challenging task. Moreover,&lt;br /&gt;
abstract data-types are a form of existential quantification over types and&lt;br /&gt;
could raise some consistency issues. We hope to find a way to incorporate&lt;br /&gt;
abstract types in PML without loosing coherence.&lt;br /&gt;
 &lt;br /&gt;
A first step would be private data types. They are a very simple yet very powerful mechanism for easily&lt;br /&gt;
ensuring invariants on all values of a data type. This mechanism is as&lt;br /&gt;
follows: the compiler simply checks that the constructors of a data type are&lt;br /&gt;
not used for constructing values. Values are constructed by using construction&lt;br /&gt;
functions, like with abstract data types. However, unlike with abstract data&lt;br /&gt;
types, constructors can still be used as patterns for defining functions by&lt;br /&gt;
pattern-matching. Hence, a library on a private data type is not closed but&lt;br /&gt;
can be extended easily. Private data types are therefore an important and very&lt;br /&gt;
useful feature for defining data structures with complex invariants and&lt;br /&gt;
proving their correctness more easily. They have been implemented in OCaml by&lt;br /&gt;
Pierre Weis and are described in Frédéric Blanqui, Thérèse Hardin and Pierre&lt;br /&gt;
Weis&#039; ESOP&#039;07 paper [BHW07].&lt;br /&gt;
&lt;br /&gt;
A second step would be existential types, which are very similar to abstract types,&lt;br /&gt;
but with no free name for the abstract type. On a logical level, they do imply an existential quantification over types&lt;br /&gt;
which has to be limited to ensure consistency. However existential types do not require the type to have a free name, which corresponds in logic to a definite description operator (similar to Hilbert&#039;s epsilon operator), and this, being connected to the axiom of choice (over types), may be really problematic for consistency. Some work related to this exists in the phd thesis of F. Ruyer, a former student of C. Raffalli [Ruy06].&lt;br /&gt;
&lt;br /&gt;
====Task 2 - termination====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Pierre Hyvernat&lt;br /&gt;
&lt;br /&gt;
Participants: Christophe Raffalli, Andreas Abel, Frederic Blanqui&lt;br /&gt;
&lt;br /&gt;
Remark: this is an essential task, running during the 4 years. There will always be some embarrassing examples that do not work, but could work... both for the core and auxiliary criterion (see below for the distinction) meaning that this research field will remain open forever.&lt;br /&gt;
&lt;br /&gt;
Even if it might be counter-intuitive at first, it is often necessary to write programs whose execution can be infinite. For example, any kind of &amp;quot;server&amp;quot;, or almost any interactive program might have infinite executions. Even in purely mathematical setting, it can be interesting to have intermediary non-terminating functions. Consider a function outputting the stream of prime numbers : even if this function is non-terminating, we might use it in a terminating manner in a proof by requesting the &#039;&#039;n&#039;&#039; first prime numbers.&lt;br /&gt;
&lt;br /&gt;
Since PML uses full recursion (keyword &amp;lt;tt&amp;gt;rec&amp;lt;/tt&amp;gt;), writing such programs is easy. On the other hand, the notion of &amp;quot;terminating&amp;quot;, or &amp;quot;well-founded&amp;quot; recursive function isn&#039;t part of the core of PML: such programs are just special cases of recursive programs. The user will have to specify which functions are in fact terminating and might have to prove it himself when PML cannot infer termination automatically.&lt;br /&gt;
&lt;br /&gt;
Proofs of specifications are just PML programs, and those cannot be allowed to run infinitely. More precisely, even if proof will never be run at all (no computational content), they are required to be well-founded. The consistency of PML relies on this. In order to relieve the user from proving that all proofs are in fact terminating, PML should offer a way to check automatically that (some) functions are terminating. Because the halting problem is undecidable, it is hopeless to do that in all generality, but this is seldom necessary: many proofs terminate for obvious reasons. PML should only work for most of the functions, most of the time (rather than work for all the functions, all the time...)&lt;br /&gt;
&lt;br /&gt;
Technically speaking, PML can infer an error called &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; when it encounters a program which, it thinks, may not terminate. Such an error cannot be captured: this is an error rather than an exception. The property we need to guarantee is that if PML doesn&#039;t infer the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; possible, then the program in question does indeed terminate. If the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; is possible for a terminating function, the user can still provide PML with a proof that this error is never raised. PML current syntax for that is &amp;lt;tt&amp;gt;[p proof ... ]&amp;lt;/tt&amp;gt; where &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; is a term and &amp;lt;tt&amp;gt;...&amp;lt;/tt&amp;gt; is a proof that &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; doesn&#039;t raise any exception nor error (this is the desired property for proofs).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.a - Core termination criterion&#039;&#039;&#039; (delivered 09/2010)&lt;br /&gt;
&lt;br /&gt;
This first test is now part of PML. Since primitive recursive function isn&#039;t enough in practice, even for proofs, a subtler and more powerful termination criterion has been implemented. This is an extension of the &amp;quot;size change principle&amp;quot; of Lee, Jones and Ben-Amram [LJ01]. This test successfully checks termination for primitive recursion, lexicographic ordering and permutation of arguments and thus covers most simple practical cases. The implementation is quite similar to the original size-change principle, but the proof of correctness is surprisingly more difficult: see [Hyv10b].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.b - Improvement of the core termination criterion&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
The size-change principle is simple and powerful, but many cases occurring in practice aren&#039;t tagged as terminating. We plan to adapt to PML a termination criterion based on the technique of type-based termination, which allow for recursive calls through size preserving functions such as &amp;lt;tt&amp;gt;List.map&amp;lt;/tt&amp;gt;. There are several possibilities, ranging from simple systems such as the one developed by Abel (RAIRO&#039;04) [Abel04], Barthe et al (MSCS&#039;04) [Bar04] or Blanqui (RTA&#039;04, CSL&#039;05) [Bla04, Bla05c], to the very rich system of Blanqui and Riba (LPAR&#039;06) [BlR06]. In the latter, given for each function some formula in Presburger arithmetic describing how the size of the output is related to the size of the inputs (the correctness of which can be checked automatically), the termination follows from the fact that recursive calls are done on strictly decreasing arguments, using for instance lexicographic or multiset comparisons together with linear combinations of the arguments. Intermediate systems, such as the one of Barthe, Grégoire and Riba (CSL&#039;08) [BGR08] which is powerful but with a lower complexity than Presburger arithmetic, have also to be considered.&lt;br /&gt;
&lt;br /&gt;
This development looks rather orthogonal to the implemented criterion and might require small modification of other parts of PML in order to get the appropriate information. On a different level, slight extensions should be added to the existing criterion to enhance its complexity on some specific examples that are recognized as termination, but not in a reasonable time.&lt;br /&gt;
&lt;br /&gt;
This core termination needs to reach an acceptable compromise between power and simplicity. In particular, the most complex developments may not find their way into the core termination criteria, but rather be used in the next task...&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.c - Use of external provers&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
In order to circumvent the limitations of the core termination criterion, we propose to use external powerful termination provers like [http://aprove.informatik.rwth-aachen.de/ Aprove] or [http://colo6-c703.uibk.ac.at/ttt2/ TTT2] that implement and combine many other termination techniques. To this end, we can define translations from PML programs to one or more of the possible formats currently used in the [http://termination-portal.org/wiki/Termination_Competition annual international competition on termination] and in particular: first-order rewrite systems (TRS), dependency pair problems (DP problem), higher-order rewrite systems (HOTRS) or Haskell programs. In particular, we could reuse some of the techniques used for converting Haskell programs into first-order DP problems in [Gie06].&lt;br /&gt;
&lt;br /&gt;
But to which extent can we trust the results of these provers? Hopefully, now, many termination provers provide certificates in a format called [http://cl-informatik.uibk.ac.at/software/cpf/ CPF] that can be checked by certified, dedicated tools like [http://cl-informatik.uibk.ac.at/software/ceta/ CeTA], [http://color.inria.fr/ Rainbow] or [http://a3pat.ensiie.fr/ CiME3].&lt;br /&gt;
&lt;br /&gt;
The most pragmatic route is simply to trust those tools and concentrate on proving that the translation from (restricted) PML code to the input language is indeed correct. Of course, the ideal solution would be to be able to translate the external certificates into an equivalent PML program whose termination can be infered by the core criterion. The complexity of tools like [http://aprove.informatik.rwth-aachen.de/ Aprove] makes it look very difficult and it is probably hopeless to do that in a general manner.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.d - Modularity and termination&#039;&#039;&#039; (beginning 09/2013, never ending)&lt;br /&gt;
&lt;br /&gt;
The core termination prover does not use the definition of functions to prove their termination, but only information gathered from the typing constraints. When using external prover, for large development, one also would like to avoid sending a large piece of code to the external prover. &lt;br /&gt;
&lt;br /&gt;
Function such as &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; preserves the length of list. But the notion of length does not appear explcitely in the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. This means that the current core termination prover often can not prove termination of a function that use &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. It also means that you need to give the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; to an external tool. &lt;br /&gt;
&lt;br /&gt;
We would like to automatically compute some concise information about the size differences between input and output of program. This means that we would like to infer (when possible) a notion of &#039;&#039;size&#039;&#039; from the definition of a function.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Remark&#039;&#039;&#039;: The halting problem is undecidable, the available external tools for checking termination are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the termination checker.&lt;br /&gt;
&lt;br /&gt;
====Task 3 - compilation ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Wojciech Matyjewicz, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.a - A first compiler using LLVM&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012) LLVM is a compiler infrastructure providing many tools: compilation strategy, virtual instruction set, compiler infrastructure, tools to write high level virtual machines, etc. LLVM is very attractive, because it is rather simple to use (it even has an OCaml interface) and can compile for a bytecode interpreter, can be used as a JIT compiler or a standard compiler. Moreover, it support a lot of platforms. It also provide some optimizations, which is important. We think that writing a compiler, with no optimization, for PML using LLVM should not be too hard (this is important that this task be easy, because this is not really research ...)&lt;br /&gt;
&lt;br /&gt;
A polish phd student Wojciech Matyjewicz has started to work on this in December. He visited the LAMA during one week to start the project. It is important to note that he is a first year phd in Poland and the first year there is equivalent to our Master 2. Which means that Wojciech Matyjewicz is a potential candidate.&lt;br /&gt;
&lt;br /&gt;
Then, we would like to improve our compiler in various direction. We mention here the ones that are innovative in this domain (we should also consider more standard optimization, but we do not mention them specifically). &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.b - Representation of cartesian product and disjoint sum&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012 for product) PML allows only one kind of cartesian product which in general (because of multiple inheritance and implicit subtyping) must be represented as a table (hash-table or maps based on binary search trees). These can impact performance. We plan to generate extra constraints for each occurrence of a constructor of a cartesian product in a program. Then, solving this constraint in a way that maximize speed (or size) should allow for a representation of cartesian product that is more efficient than using, for instance, OCaml. The same kind of optimization (with a different optimization criterion) should be done for sum types and the implementation of pattern matching. This optimization should be included in the first compiler because the implantation with tables is too costly for a temporary solution.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.c - Unboxing&#039;&#039;&#039; (depends on some parts of 3.b, beginning 1/2012, delivered 1/2013) In general, 32 bits integer and floating point number are boxed (that is represented by a pointer). This allows a more elegant language. This can lead to major impact on performance especially when arrays are involved. We think that constraint-checking is a good framework to propagate type information and allow efficient unboxing. Nevertheless, doing enough unboxing to try to match the performance of low level languages like C is very hard. We hope that we can reuse some of the work of task 3.b, because unboxing can be seen also as the optimization of the representation of a cartesian product with only one field.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.d - compilation of affectation (reference and arrays) and IO&#039;&#039;&#039; (depend upon 1.c, beginning 09/2012, delivered 03/2014) After adapting uniqueness typing to PML (task 1.c), we will be able to compile affectation and IO imperatively as in any imperative programming language.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.e - Garbage collection&#039;&#039;&#039; (beginning 01/2014, delivered 09/2014) For simplicity reasons, the first compiler will simply use Boehm&#039;s garbage collector. This garbage collector is relatively efficient and simple to use. However, Boehm&#039;s GC isn&#039;t optimized for the kind of allocations used in a functional language. Moreover, having a multithreaded GC could prove useful in moder environment. We thus plan to replace Boehm&#039;s GC by a dedicated GC tuned for our purposes.&lt;br /&gt;
&lt;br /&gt;
Writing a GC that is both efficient and correct is not easy, and this sub-task is rather orthogonal to the PML language, which explains why it only comes later during the project. Nevertheless, we feel it is necessary to go through the trouble if we want to be as efficient (or even better, more efficient) than existing functional languages...&lt;br /&gt;
&lt;br /&gt;
====Task 4 - Automated reasoning====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Frédéric Blanqui&lt;br /&gt;
&lt;br /&gt;
Participants: Frédéric Blanqui, Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
The kernel of the proof engine will be based on completion techniques. Knuth-Bendix completion tries to transform a set of unoriented equations into a set of (inter-reduced and) convergent, that is, terminating and confluent, set of rewrite rules. It can therefore be used for proving that some equality is the equational consequence of some equational theory. Indeed, when an equational theory can be completed into a convergent rewrite system, two terms are equivalent in this equational theory if their normal form in the convergent rewrite systems are equal.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.a - Adaptation of the Knuth-Bendix completion algorithm to PML&#039;&#039;&#039; (already started, delivered 09/2015) As explained just before, Knuth-Bendix completion is based on rewriting. However, in PML, programs are not rewriting systems. We therefore need to adapt Knuth-Bendix completion. We need both generalization, to use the notion of constructor present in ML and take care of the higher-order nature of ML (even if we can not hope much here).&lt;br /&gt;
As said above, something is already implemented, but it is trivial because completely restricted to closed terms. A first version should be able at least to rewrite a closed term modulo some simple equational (and universal) theory. An important point here is to ensure termination&lt;br /&gt;
of this algorithm and even a low complexity. The price to pay, will be incompleteness. A lot of care should also be devoted to the correctness of the implementation, because like for task 3.a, the consistency of PML relies on it.&lt;br /&gt;
&lt;br /&gt;
This task in one of the major task for PML and a first version already exists, but is non terminating in presence of equalities between functions: if we have an equation like &#039;&#039;f = f o f&#039;&#039;, PML may use this equation has a definition of &#039;&#039;f&#039;&#039; and loop. For dealing with these cases, we are considering a fix which involves some notions similar to those of &#039;&#039;geometry of interaction&#039;&#039;. Another particular and very important case of universal equation that we should take into account is associativity and commutativity. It is indeed very important to ease proofs on integers (addition and multiplication are associative and commutative). To this end, we could reuse the [http://cime.lri.fr CiME] library.&lt;br /&gt;
&lt;br /&gt;
Note that this work could benefit to other projects and tools, like [http://moca.inria.fr/ Moca], a generator of construction functions for private data types with algebraic invariants, also based on completion, or Europa, a proof assistant based on the lambda-pi-calculus modulo rewriting developed by Gilles Dowek and [http://www.lix.polytechnique.fr/Labo/Mathieu.Boespflug/ Mathieu Boespflug]. Indeed, currently, Moca generates OCaml code without guarantee on its correctness. Using PML instead, Moca could also generate a proof of the correctness of the generated construction functions.&lt;br /&gt;
Then, later, when trying to prove the correctness of a function defined on this private date type, one can use the invariants satisfied by the values of the private data type as assumptions, since these invariants are satisfied by construction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.b - Use of external provers&#039;&#039;&#039; (beginning 03/2012, delivered 09/2015) Like for termination proofs, in order to increase the proving capacities of PML, we will provide a translation of PML proof goals into the [http://www.cs.miami.edu/~tptp/ TPTP standard format] of the CASC competition in order to be able to use external provers too, and in particular provers based on completion like [http://www.waldmeister.org/ Waldmeister], [http://cime.lri.fr/ CiME] or [http://cl-informatik.uibk.ac.at/mkbtt/ mkbTT] but not only. And possibly some certifying provers like [http://focal.inria.fr/zenon/ Zenon] based on tableaux or [http://alt-ergo.lri.fr/ Alter-Ego] based on SMT (SAT solver modulo theory).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Same remark than for termination&#039;&#039;&#039;: The problem is undecidable, the available external tools for automated reasonning are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the automated reasonning.&lt;br /&gt;
&lt;br /&gt;
====Task 5 - validation (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Christophe Mouilleron, Tom Hirschowitz.&lt;br /&gt;
&lt;br /&gt;
The validation requires to write numerous examples to check that we fulfill our main goal, which is that all programs (with or without proof) are written in the best possible way. This work being research, we think that it is important that any piece of code written in PML that does not look &#039;&#039;right&#039;&#039; is carefully examined to check that this is not due to a defect in language design.&lt;br /&gt;
&lt;br /&gt;
Christophe Mouilleron and Erik Martin-Dorel started to work on the axiomatization of computer arithmetics within an ongoing PEPS project. This is a good test for PML and moreover a requirement &lt;br /&gt;
because we want PML to be a real programming language and therefore the limited arithmetic of processors (32 and 64 bits integer and floating point number) must be supported by PML. However, proving software using them is not trivial at all and Christophe Mouilleron member of the Arénaire team in ENS Lyon is a specialist in this domain.&lt;br /&gt;
&lt;br /&gt;
Tom Hirschowitz and Christophe Raffalli already started (and almost finished) a proof in PML that &lt;br /&gt;
categories, functors and natural transformations form a 2-category (this development is available in the example directory in the current version of PML). We plan to continue such abstract developments and we think that they could lead to interesting perspectives about the modularity of PML.&lt;br /&gt;
&lt;br /&gt;
More general code, including a standard library and some significant mathematics should be developed (there is already around 10.000 lines of PML code in the current distribution). Moreover, we started to port Pierce et al.&#039;s course, in Coq, on software foundations (http://www.cis.upenn.edu/~bcpierce/sf/), to PML. The first three files are translated and there remain a dozen of files of around 2500 lines to translate. This is a major work, but would provide a very good test for PML, and a good tutorial.&lt;br /&gt;
&lt;br /&gt;
This task should deliver at least 100.000 lines of PML code to have&lt;br /&gt;
a sufficient corpus to say in which respect we fulfilled our goals.&lt;br /&gt;
&lt;br /&gt;
==== Task 6 - Optimization of PML (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: C. Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: All (anyone could optimize the part of PML he was involved in).&lt;br /&gt;
&lt;br /&gt;
Some of the choice in the design of PML involve rather complex algorithm. Notably, this is the case of the constraint checking algorithm and completion procedure. The first implementation is not trivial but not optimized either. And very often, we have discoverd and will continue to discover that PML is too slow. This goal of this transversal task is to ensure that PML is usable. &lt;br /&gt;
&lt;br /&gt;
Currently, some optimisations were already added. For instance, PML uses a sat solver for various &lt;br /&gt;
tasks: completeness and usefulness of cases in pattern matching and dealing with negative &lt;br /&gt;
hypothesis (like &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is not equal to &amp;lt;tt&amp;gt;S[x]&amp;lt;/tt&amp;gt;) in the completion procedure. Improving the sat solver using J.C. Filliâtre work [] and simplifying the formula before giving them to the sat solver were a major improvement.&lt;br /&gt;
&lt;br /&gt;
A lot of other optimisations are planned: &lt;br /&gt;
* The graph used to encode the typing constraints should probably be reduced (that is we should compute its transitive reduction). &lt;br /&gt;
* The completion procedure stores a set of terms of the language and we need a fast way to recover the set of all term using a given sub-term. The current implementation is too naive. &lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
=== Planning of tasks, deliverables and milestones ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The following diagram represents the summary of the tasks and subtasks, together with the intended planning:&lt;br /&gt;
&lt;br /&gt;
[[Image:pml-gantt.png]]&lt;br /&gt;
&lt;br /&gt;
==Data management, data sharing, intellectual property and results exploitation==&lt;br /&gt;
&lt;br /&gt;
Results in each of the tasks will be published in journals (APAL, TCS, ...) and international conferences as usual (LICS, TLCA, CSL, CIE, ...).&lt;br /&gt;
&lt;br /&gt;
PML language is already distributed as open source software under the Cecill-B license. We think that for such a research platform, this is the only possible way to ensure that people will try it. As soon as a first compiler is available, we plan to produce easy-to-install packages, at least for some well-known Linux distributions (Debian and its derivatives seem a good choice).&lt;br /&gt;
&lt;br /&gt;
==Consortium organization and description==&lt;br /&gt;
&lt;br /&gt;
===Relevance of the partner for the project===&lt;br /&gt;
&lt;br /&gt;
This project involve only one partner, the LAMA (UMR 5127), where the coordinator of the project already developed the proof assistant PhoX. The main characteristic of PhoX is to be rather simple to use due to a set of tactics which is limited (less than 20 for the principal ones), but powerful. Moreover, tactics are extensible by &#039;&#039;incorporating theorems&#039;&#039; inside the tactics.&lt;br /&gt;
&lt;br /&gt;
Clearly, this means that efficiency was the main goal of PhoX. Unfortunately, like all tactical theorem prover, PhoX proofs are not readable. After a few attempts with a Mizar-like mode for PhoX, Christophe Raffalli decided to move to a new theorem prover, starting from scratch.&lt;br /&gt;
&lt;br /&gt;
Pierre Hyvernat is also in Chambery and the second developer of PML (he wrote the current termination checker). Tom Hirshowitz has some prior experience in his phd about the compilation of functional languages. At ENS Lyon, which is very near to Chambéry, Alexandre Miquel is a specialist of consistency proof for logical framework. Therefore, Chambery is the very natural partner for this project.&lt;br /&gt;
&lt;br /&gt;
===Qualification of the project coordinator and members===&lt;br /&gt;
&lt;br /&gt;
The coordinator and various members of the project comes from various horizon (see section 7), but they have a common background around the use and development of programming language and/or formal methods. We think that this variety, the small number of members, should allow for good communication and should be very fruitful. &lt;br /&gt;
&lt;br /&gt;
We think, that compared with the development of PML by Christophe Raffalli alone, such a team should speed up the development of PML approximately by a factor 3, making it possible to deliver a very innovative and useful tool at the end of the project. The lack of support for such a team would certainly limit the tool to an experimental toy with many development only partially (or even not at all) integrated in the project.&lt;br /&gt;
&lt;br /&gt;
Christophe Raffalli will also ask for delegations during the project to be able to spend even more time on it.&lt;br /&gt;
&lt;br /&gt;
==Scientific justification of requested budget==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Meetings (total 9720€ per year)====&lt;br /&gt;
 &lt;br /&gt;
Two meetings and one workshop per year, 3 days each, for 7 people. Each meeting costs&lt;br /&gt;
1 train ticket in France, 3 days and 2 nights:&lt;br /&gt;
3*7*(100 + 3*20 + 2*80) = 6720€. &lt;br /&gt;
&lt;br /&gt;
For the workshop, we have to invite 2 to 3 guests. Some may come from foreign country and we estimate the cost&lt;br /&gt;
to 3000€ per year. Which mean a total of 9720€ per year.&lt;br /&gt;
&lt;br /&gt;
====Visits (total 10000€)====&lt;br /&gt;
&lt;br /&gt;
We think that this is very important for this project to interact with other project.&lt;br /&gt;
For instance, Andreas Abel came to visit Chambéry in 2010 for two weeks financed by our PEPS&lt;br /&gt;
project and during this time induced an important bootstrap to the implementation of the termination checker &lt;br /&gt;
[Hyv10b] and contributed a non trivial example with a proved implantation of left-leaning red-black trees.&lt;br /&gt;
&lt;br /&gt;
We want to continue such interaction. Andreas Abel already agreed as well as Joe Wells for discusion about error reporting and , Assia Mahboubi for complex proofs involving the reflexion principle. Many other discussion would be profitable about PML runtime (with multithreading ?), interaction with external tools (termination checker or automated theorem prover), &lt;br /&gt;
uniqueness typing (meeting with people already using such technics), ...&lt;br /&gt;
&lt;br /&gt;
We plan around 4 short visits of one or two weeks from people outside the project to Chambéry and the same amount for short visit in the other direction. This means around 12 weeks per year with 8 travels for a cost of 500€ per week (x12) plus in average (depending if we use plane or train) the same amount for each travel (x8), with a total of 10000€ per year.&lt;br /&gt;
&lt;br /&gt;
====Conferences (total 9600€ per year)====&lt;br /&gt;
 &lt;br /&gt;
The members of the ANR will submit papers to international conferences and&lt;br /&gt;
journals and attend to specialized workshop. We have 2.5 person/year on the project with means &lt;br /&gt;
around 3 international conferences or workshop per year (estimated cost 2000€) and one national conference or workshop per year (estimated cost 1200€)&lt;br /&gt;
&lt;br /&gt;
====Master internships (total 1500€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We plan to host around four master internships in good conditions (possibly&lt;br /&gt;
followed by PhD studentships not financed by the ANR): one per year with a total cost of&lt;br /&gt;
6000€ (1500€ each: 300€ for travel and 200€ per month for an accommodation at&lt;br /&gt;
the CROUS).&lt;br /&gt;
&lt;br /&gt;
====Computers (total 2000€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We consider that the ANR project has to participate in the renewal of the&lt;br /&gt;
computers of its participants. The lifetime of a computer being 4 years and&lt;br /&gt;
the total number of month for permanent members of the project being 112, we&lt;br /&gt;
think that we should pay for 4 computers with an average value of 2000€ each&lt;br /&gt;
(we need powerful computers and laptops, because automated reasoning requires&lt;br /&gt;
a lot of computations and memory).&lt;br /&gt;
&lt;br /&gt;
====Human resources financed by the ANR (1 PhD student, 2 two years postdocs and 4 month of invited professor)====&lt;br /&gt;
 &lt;br /&gt;
This project involves many tasks and 7 members. However, all members&lt;br /&gt;
apart from the coordinator and Pierre Hyvernat can only devote 2-3 month per year to this project&lt;br /&gt;
(they are involved in other ongoing research). Although this is far from&lt;br /&gt;
negligible, we think that we will need more human power: we estimate that 1&lt;br /&gt;
PhD and 2 postdocs are reasonable. &lt;br /&gt;
&lt;br /&gt;
We also consider that one year post-doc are not sufficient, because the time need to &lt;br /&gt;
understand the existing code base is long and the student has both to write code and &lt;br /&gt;
publish its result. Moreover, the code produced by the student will not be an experimental&lt;br /&gt;
code to support its publication, but code which should remain in the project and be maintened by &lt;br /&gt;
other member of the project. In one year, this seems impossible to achieve.&lt;br /&gt;
&lt;br /&gt;
Moreover, as mentioned in the section about visits, we would like to have 1 month per year of invited professor.&lt;br /&gt;
&lt;br /&gt;
This would give a total 88 months (4 month invited, 36 for the PhD and 48 for the 2 postdocs)&lt;br /&gt;
To be compared with the total of 104/112 month not payed by the ANR. We consider that this is a good balance.&lt;br /&gt;
&lt;br /&gt;
The total cost is 308589€.&lt;br /&gt;
&lt;br /&gt;
====Human resources not financed by the ANR====&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! month/year&lt;br /&gt;
! percentage&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Raffalli&lt;br /&gt;
| 10&lt;br /&gt;
| 85%&lt;br /&gt;
|-&lt;br /&gt;
| Frédéric Blanqui&lt;br /&gt;
| 4&lt;br /&gt;
| 25%&lt;br /&gt;
|-&lt;br /&gt;
| Emmanuel Chailloux&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Tom Hirshowitz&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Pierre Hyvernat&lt;br /&gt;
| 6&lt;br /&gt;
| 50%&lt;br /&gt;
|-&lt;br /&gt;
| Alexandre Miquel&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Mouilleron&lt;br /&gt;
| 0/2&lt;br /&gt;
| 0/15%&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total per year&#039;&#039;&#039;&lt;br /&gt;
| 26/28&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total for 4 year&#039;&#039;&#039;&lt;br /&gt;
| 104/112&lt;br /&gt;
| &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Remark: the situation of Christophe Mouilleron is unknown next year. If it is possible he will &lt;br /&gt;
continue is work on PML started with the PEPS for around 2 month per year. But if it is not possible, &lt;br /&gt;
or if he is selected for the post-doc position, then we should not count it. We used the worst case&lt;br /&gt;
on the website.&lt;br /&gt;
&lt;br /&gt;
The total cost is 350333€, ignoring Christophe Mouilleron.&lt;br /&gt;
&lt;br /&gt;
==Annexes==&lt;br /&gt;
&lt;br /&gt;
===CV, Resume of all project members===&lt;br /&gt;
&lt;br /&gt;
==== Christophe Raffalli (project coordinator) ====&lt;br /&gt;
&lt;br /&gt;
Age 41, MCF at the LAMA (UMR 5127) since September 1997.&lt;br /&gt;
&lt;br /&gt;
After his PhD in Paris VII (defended in February 1994), Christophe Raffalli spent 1 and a half year at the LFCS in Edinburgh, 2 years at Chalmers university in Göteborg (post-doc of the TYPES European project) and 1 year as ATER in Créteil University.&lt;br /&gt;
&lt;br /&gt;
Research administration: For ten years, the LAMA was sub-site of the Paris VII site inside the TYPES project which was renewed several times and Christophe Raffalli was the coordinator for this sub-site. Currently the project is not financed by the E.U. Nevertheless, Christophe Raffalli is in charge of the organization of the next TYPES meeting in Aussois in May 2009.&lt;br /&gt;
&lt;br /&gt;
His research interests include:&lt;br /&gt;
&lt;br /&gt;
* theory and implementation of proof assistants,&lt;br /&gt;
* proof theory,&lt;br /&gt;
* implementation of programming languages (especially type-systems).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Raf10b] &#039;&#039;Realizability for programming languages&#039;&#039; (submitted, available as hal-00474043)&lt;br /&gt;
&lt;br /&gt;
* [Raf08a] &#039;&#039;PML and strong normalization&#039;&#039; conference at the Types workshop, April 2008, Turino, Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf07b] &#039;&#039;PML: a new proof assistant&#039;&#039; conference at the Types workshop, may 2007, Cividale del Friuli (Udine), Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf06a] &#039;&#039;Realizability of the axiom of choice in HOL (An analysis of Krivines&#039;s work)&#039;&#039; with Frédéric Ruyer in Fundamenta Informaticae (2006)&lt;br /&gt;
&lt;br /&gt;
* [Raf05a] &#039;&#039;PhoX&#039;&#039; with Paul Rozière in The seventeen provers of the World, Freek Wiedijk (editor) LNAI 3600 pages 67-71&lt;br /&gt;
&lt;br /&gt;
* [Raf03b] &#039;&#039;System ST&#039;&#039; Schedae Informatica, proceedings of the Chambery-Krawow-Lyon Workshop, Vol. 12, pages 97-112 (June 2003)&lt;br /&gt;
&lt;br /&gt;
* [Raf02c] &#039;&#039;Getting results from programs extracted from classical proofs&#039;&#039;, TCS 2004, volume 323, pages 49-70&lt;br /&gt;
&lt;br /&gt;
* [Raf02b] &#039;&#039;System ST, beta-reduction and completeness&#039;&#039;, presented at LICS 2003, publication IEEE, pages 21-32&lt;br /&gt;
&lt;br /&gt;
* [Raf02a] &#039;&#039;Computer Assisted Teaching in Mathematics&#039;&#039;, with René David, to appear in the proceedings of the Workshop on 35 years of Automath (April 2002, Edingurgh)&lt;br /&gt;
&lt;br /&gt;
* [Raf01d] &#039;&#039;System ST, towards a Type System for Extraction and Proof of Programs&#039;&#039;, Archive for Pure and Applied Logic, 2003, volume 122, pages 107-130&lt;br /&gt;
&lt;br /&gt;
* [Raf01c] &#039;&#039;Apprentissage du raisonnement assité par ordinateur&#039;&#039;, avec René David, Quadrature numéro 45, printemps 2002, pages 25-36). Version courte parue dans la gazette de la SMF, avril 2002, numéro 92, pages 48-56&lt;br /&gt;
&lt;br /&gt;
==== Frederic Blanqui (INRIA, Rocquencourt) ====&lt;br /&gt;
&lt;br /&gt;
Age 38, permanent full-time researcher at [http://www.inria.fr INRIA].&lt;br /&gt;
&lt;br /&gt;
Frederic Blanqui is expert in the following areas:&lt;br /&gt;
* type theory,&lt;br /&gt;
* rewriting theory,&lt;br /&gt;
* termination,&lt;br /&gt;
* functional programming,&lt;br /&gt;
* proof assistants,&lt;br /&gt;
* and formal certification of program properties.&lt;br /&gt;
&lt;br /&gt;
Since September 2008, he is INRIA researcher at [http://liama.ia.ac.cn LIAMA], the Sino-French Laboratory in Computer Science, Automation and Applied Mathematics.&lt;br /&gt;
&lt;br /&gt;
Between 2003 and 2008, he was INRIA researcher at [http://www.loria.fr LORIA], Nancy, in the Protheo research team led by Pr Claude Kirchner, focusing on the use of rewriting techniques for programming, as well as specifying and proving program properties.&lt;br /&gt;
&lt;br /&gt;
Since 2004, he is leading the [http://color.inria.fr CoLoR] project which aims at providing tools for automatically certifying the termination of programs. Since 2007, CoLoR is the best certification back-end in the international [http://termination-portal.org/wiki/Termination_Competition competition on certified termination provers].&lt;br /&gt;
&lt;br /&gt;
In 2007 and 2008, he led the INRIA [http://quotient.loria.fr/ Quotient] project which aims at extending the [http://caml.inria.fr OCaml] programming language with types whose values automatically satisfy equational invariants using the [http://moca.inria.fr Moca] tool.&lt;br /&gt;
&lt;br /&gt;
He supervised 2 master thesis and 3 PhD students on the extension of type theory with decision procedures, the termination of typed higher-order rule-based programs, and the certification of termination proofs.&lt;br /&gt;
&lt;br /&gt;
He did his PhD with Pr Jean-Pierre Jouannaud at University Paris Sud between October 1998 and September 2001 on the combination of type theory and rewriting theory.&lt;br /&gt;
&lt;br /&gt;
Between October 2001 and August 2002, he worked on the certification of cryptographic protocols with Pr Larry Paulson at Cambridge, UK.&lt;br /&gt;
&lt;br /&gt;
Between September 2002 and September 2003, he worked at Ecole Polytechnique in the [http://coq.inria.fr Coq] development team on the extension of the proof assistant Coq with rewriting.&lt;br /&gt;
&lt;br /&gt;
More details on his activities and publications can be found on his [http://www-rocq.inria.fr/~blanqui/ web page] and in his [http://www-rocq.inria.fr/~blanqui/divers/cv.pdf CV].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
International journals with reading committee: 7&lt;br /&gt;
&lt;br /&gt;
International conferences with reading committee: 15&lt;br /&gt;
&lt;br /&gt;
Other publications (thesis, workshops, invited papers, reports, etc.): 15&lt;br /&gt;
&lt;br /&gt;
Prizes: 2001 [http://www.specif.org/ SPECIF] Award for his PhD thesis by the French national society of teachers and researchers in computer science; and 2001 Kleene Award for the best young researcher paper at the IEEE Symposium on Logic in Computer Science ([http://www2.informatik.hu-berlin.de/lics/ LICS]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Five most significant publications in the last 5 years:&lt;br /&gt;
&lt;br /&gt;
* [Bla11] F. Blanqui and A. Koprowski. &#039;&#039;CoLoR: a Coq library on well-founded rewrite relations and its application to the automated verification of termination certificates&#039;&#039;. To appear in Mathematical Structures in Computer Science.&lt;br /&gt;
&lt;br /&gt;
* [BRK10] F. Blanqui, C. Riba and C. Kirchner. &#039;&#039;On the confluence of lambda-calculus with conditional rewriting&#039;&#039;. Theoretical Computer Science 411(37), p. 3301-3327.&lt;br /&gt;
&lt;br /&gt;
* [BR09] F. Blanqui and C. Roux. &#039;&#039;On the relation between sized-types based termination and semantic labelling&#039;&#039;. CSL&#039;09. LNCS 5771.&lt;br /&gt;
&lt;br /&gt;
* [BJS08] F. Blanqui, J.-P. Jouannaud and P.-Y. Strub. &#039;&#039;From formal proofs to mathematical proofs: a safe, incremental way for building in first-order decision procedures&#039;&#039;. TCS&#039;08. IFIP 273.&lt;br /&gt;
&lt;br /&gt;
* [BHW07] F. Blanqui, Thérèse Hardin and Pierre Weis. &#039;&#039;On the Implementation of Construction Functions for Non-free Concrete Data Types&#039;&#039;. ESOP 2007: 95-109.&lt;br /&gt;
&lt;br /&gt;
==== Emmanuel Chailloux (LIP6, Paris) ====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Age 51,  full professor at the University &lt;br /&gt;
Pierre et Marie Curie ([http://www.upmc.fr UPMC - Paris 6]) in Paris France, &lt;br /&gt;
and since October 2006  researcher at the &lt;br /&gt;
[http://www.lip6.fr LIP6] computer science laboratory (UMR 7606), &lt;br /&gt;
in the &amp;quot;Algorithms, Programs and Resolution&amp;quot; team ([http://www-apr.lip6.fr APR]).&lt;br /&gt;
&lt;br /&gt;
His research work is related to design and implementation of programming languages : &lt;br /&gt;
* semantics, &lt;br /&gt;
* types systems, &lt;br /&gt;
* runtime implementation, &lt;br /&gt;
* multicores. &lt;br /&gt;
Most of the recent publications relate to safety-critical software development.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Recent publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[VWC-2011] Vaugon B., Wang P., Chailloux E. &#039;&#039; Les microcontrôleurs&lt;br /&gt;
PIC programmés en Objective Caml&#039;&#039;. Journées des Langages Applicatifs&lt;br /&gt;
(JFLA&#039;2011), janvier 2011.&lt;br /&gt;
&lt;br /&gt;
[WJC-2010] Wang P., Jonquet A., Chailloux E. &#039;&#039;Non-Intrusive&lt;br /&gt;
Structural Coverage for Objective Caml&#039;&#039;.  5th Workshop on Bytecode&lt;br /&gt;
Semantics, Verification, Analysis and Transformation (Bytecode), 2010.&lt;br /&gt;
&lt;br /&gt;
[PAMCCWMC-2009] Pagano B., Andrieu O., Moniot T., Canou B., Chailloux&lt;br /&gt;
E., Wang P., Manoury P., Colaço J.-L. &#039;&#039;Experience Report: Using&lt;br /&gt;
Objective Caml to develop safety-critical embedded tool in a&lt;br /&gt;
certificaiton framework&#039;&#039;.  International Conference of Functional&lt;br /&gt;
Programming (ICFP&#039;09), 2009.&lt;br /&gt;
&lt;br /&gt;
[CBC-2008] Canou B., Balat V., Chailloux E. &#039;&#039;O&#039;Browser : Objective&lt;br /&gt;
Caml on browsers&#039;&#039;. The 2008 ACM SIGPLAN Workshop on ML, 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;HIRONDML: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 2008, 55--69.&lt;br /&gt;
&lt;br /&gt;
[PACCCMW-2008] Pagano B., Andrieu O., Canou B., Chailloux E., Colaço J.-L., Moniot T., Wang P. &lt;br /&gt;
&#039;&#039;Certified development tools implementation in objective caml.&#039;&#039;  &lt;br /&gt;
International Symposium on Practical Aspects of Declarative Languages (PADL 08), 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;Hirondml: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 (2008) 55-69&lt;br /&gt;
&lt;br /&gt;
[HMC-2007] Henry G., Mauny M., Chailloux E. &#039;&#039;Typer la désérialisation&lt;br /&gt;
sans sérialiser les types&#039;&#039;. Technique et Science Informatiques 26, 9&lt;br /&gt;
(2007) 1067-1090.&lt;br /&gt;
&lt;br /&gt;
[CM-2006] Chailloux E., Mauny M. &#039;&#039;Programmation fonctionnelle&#039;&#039;.&lt;br /&gt;
Encyclopédie de l&#039;informatique et des systèmes d&#039;information (2006)&lt;br /&gt;
1016--1027.&lt;br /&gt;
&lt;br /&gt;
==== Tom Hirschowitz (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
34 ans, CR CNRS (informatique) , LAMA&lt;br /&gt;
&lt;br /&gt;
* 2007         CR CNRS au LAMA (UMR 5127) à Chambéry&lt;br /&gt;
* 2004-2007    CR CNRS au LIP (UMR5668) à Lyon&lt;br /&gt;
* 2003-2004    ATER, équipe Plume, LIP, ENS Lyon&lt;br /&gt;
* 2000-2003    Doctorat (dir.: X. Leroy, INRIA Rocquencourt, projet Cristal)&lt;br /&gt;
* 1999-2000    DEA à Paris 7&lt;br /&gt;
* 1996-2000    Ecole Nationale des Ponts et Chaussées&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;10 publications dans des revues et conférences internationales&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;publications choisies&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
# T. Hirschowitz, X. Leroy, and J. B. Wells. Compilation of extended recursion in call-by-value functional languages, PPDP 2003. Version journal dans Higher-Order and Symbolic Computation 22-1. 2009.&lt;br /&gt;
# R. Garner, T. Hirschowitz, and A. Pardon. Variable Binding, Symmetric Monoidal Closed Theories and Bigraphs. CONCUR&#039;09. 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. Contraction-free Proofs and Finitary Games for Linear Logic. MFPS, 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. A Theory for Game Theories. FSTTCS, 2007.&lt;br /&gt;
# T. Hirschowitz, X. Leroy. Mixin Modules in a Call-by-Value Setting, ESOP, 2002, journal version in ACM Transactions on Programming Languages and Systems, 2005.&lt;br /&gt;
&lt;br /&gt;
==== Pierre Hyvernat (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
Age 30, &amp;quot;maître de conférences&amp;quot; at the Université de Savoie (in Chambéry) since September 2006, member of the [http://www.lama.univ-savoie.fr LAMA].&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2005, under the supervision of Thierry Coquand (Chalmers, Göteborg, Sweden) and Thomas Ehrhard (at the time, IML, Luminy, Marseille, France)&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include&lt;br /&gt;
* denotational semantics,&lt;br /&gt;
* type theory and constructive mathematics.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Hyv10b] &#039;&#039;The Size-Change Termination Principle for Constructor Based Languages&#039;&#039; (hal-00547440, submitted)&lt;br /&gt;
&lt;br /&gt;
* [HHy06] with P. Hancock: &#039;&#039;Programming Interfaces and Basic Topology&#039;&#039;. &amp;quot;Annals of Pure and Applied Logic&amp;quot;, volume 137, January 2006,&lt;br /&gt;
&lt;br /&gt;
* [Hyv05] &#039;&#039;Synchronous Games, Simulations and lambda-calculus&#039;&#039;, proceedings of the &amp;quot;GaLoP&amp;quot; workshop, ETAPS 2005. (journal version submitted to Annals of Pure and Applied Logic),&lt;br /&gt;
&lt;br /&gt;
* [Hyv04] &#039;&#039;Predicate Transformers and Linear Logic: yet another Denotational Model&#039;&#039;, Lecture Notes in Computer Science, vol. 3210, September 2004.&lt;br /&gt;
&lt;br /&gt;
==== Alexandre Miquel (PPS, Paris 7) ====&lt;br /&gt;
&lt;br /&gt;
Age 37, &amp;quot;maître de conférences&amp;quot; at the Université Paris-Diderot (Paris 7) since September 2003, member of [http://www.pps.jussieu.fr/ PPS]. Currently CNRS research associate (&amp;quot;délégation&amp;quot;) in the Plume team at the LIP (ENS Lyon) since September 2008.&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2001, under the supervision of Hugo Herbelin (INRIA/LIX) in the Coq team (now TypiCal).&lt;br /&gt;
&lt;br /&gt;
From October 2001 to August 2002 he was postdoc in the Chalmers Institute of Technology (Göetborg, Sweden) under the supervision of Thierry Coquand, and from September 2002 to August 2003 he was &amp;quot;ATER&amp;quot; at the LRI (Orsay).&lt;br /&gt;
&lt;br /&gt;
He is a specialist of the models of type theory (especially the calculus of constructions) and of the correspondence between set theory and type theory. His research interests also include:&lt;br /&gt;
* logic, proof-theory, rewriting,&lt;br /&gt;
* denotational semantics (set- and domain-theoretic),&lt;br /&gt;
* realizability in classical logic.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
His most significant publications are:&lt;br /&gt;
&lt;br /&gt;
* [Miq07] &#039;&#039;Classical program extraction in the calculus of constructions&#039;&#039; (CSL&#039;07),&lt;br /&gt;
&lt;br /&gt;
* [Miq06] with A. Arbiser and A. Ríos. &#039;&#039;A lambda-calculus with constructors&#039;&#039; (RTA&#039;06),&lt;br /&gt;
&lt;br /&gt;
* [Miq04] &#039;&#039;Lambda-Z: Zermelo&#039;s Set Theory as a PTS with 4 Sorts&#039;&#039; (TYPES&#039;04),&lt;br /&gt;
&lt;br /&gt;
* [Miq03] &#039;&#039;A Strongly Normalising Curry-Howard Correspondence for IZF Set Theory&#039;&#039; (CSL&#039;03),&lt;br /&gt;
&lt;br /&gt;
* [Miq00] &#039;&#039;A Model for Impredicative Type Systems with Universes, Intersection Types and Subtyping&#039;&#039; (LICS&#039;00).&lt;br /&gt;
&lt;br /&gt;
==== Christophe Mouilleron (LIP, ENS de Lyon) ====&lt;br /&gt;
&lt;br /&gt;
Age 26, PhD student in the Arenaire team at the LIP (ENS de Lyon) since September 2008. He works under the supervision of Claude-Pierre Jeannerod (INRIA/LIP) and Gilles Villard (CNRS/LIP).&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include :&lt;br /&gt;
* computer arithmetic,&lt;br /&gt;
* code generation,&lt;br /&gt;
* formal proof of numerical properties in programs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [MouRev10] C. Mouilleron and G. Revy. &#039;&#039;Automatic Generation of Fast and Certified Code for Polynomial Evaluation.&#039;&#039; (submitted, available as ensl-00531721)&lt;br /&gt;
&lt;br /&gt;
* [JeaMou10] C.-P. Jeannerod and C. Mouilleron. &#039;&#039;Computing Specified Generators of Structured Matrix Inverses.&#039;&#039; (ISSAC&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [BJJK+10] C. Bertin, C.-P. Jeannerod, J. Jourdan-Lu, H. Knochel, C. Monat, C. Mouilleron, J.-M. Muller, and G. Revy. &#039;&#039;Techniques and tools for implementing IEEE 754 floating-point arithmetic on VLIW integer processors.&#039;&#039; (PASCO&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [LTdD+10] V. Lefèvre, P. Théveny, F. de Dinechin, C.-P. Jeannerod, C. Mouilleron, D. Pfannholzer, and N. Revol. &#039;&#039;LEMA : Towards a Language for Reliable Arithmetic.&#039;&#039; (PLMMS&#039;10)&lt;br /&gt;
&lt;br /&gt;
===Relevant publications by non participants to the project ===&lt;br /&gt;
&lt;br /&gt;
Here are some publication or resources of interest for the project:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Laguage design and theory:&#039;&#039;&#039;&lt;br /&gt;
* [SOW97] Martin Sulzmann, Martin Odersky, Martin Wehr, &#039;&#039;Type inference with constrained types&#039;&#039;, TAPOS, 1997.&lt;br /&gt;
* [HW04] Christian Haack and J. B. Wells, &#039;&#039;Type error slicing in implicitly typed higher-order languages&#039;&#039;, Sci. Comput. Programming, 50:189-224, 2004.&lt;br /&gt;
* [Ruy06] Frédéric Ruyer, &#039;&#039;Preuves, types et sous-type&#039;&#039;, phd 2006 directed by C. Raffalli.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Termination:&#039;&#039;&#039;&lt;br /&gt;
* [LJ01] Lee, Jones, et al. &#039;&#039;The size-change principle for program termination&#039;&#039; - ACM SIGPLAN Notices - 2001&lt;br /&gt;
* [Abel04] Andreas Abel, &#039;&#039;Termination Checking with Types&#039;&#039; ,Special Issue: Fixed Points in Computer Science (FICS&#039;03 and RAIR&#039;04)&lt;br /&gt;
* [Bar04]   G. Barthe, M. J. Frade  and E. Giménez, L. Pinto and T. Uustalu, &#039;&#039;Type-Based Termination of Recursive Definitions&#039;&#039;, 2004, Mathematical Structures in Computer Science.&lt;br /&gt;
* [Gie06] J. Giesl, S. Swiderski, P. Schneider-Kamp, and R. Thiemann &#039;&#039;Automated Termination Analysis for Haskell: From Term Rewriting to Programming Languages&#039;&#039;, Proceedings of the 17th International Conference on Rewriting Techniques and Applications (RTA-06), Lecture Notes in Computer Science 4098.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;the Clean language:&#039;&#039;&#039;&lt;br /&gt;
* [AGR92] Peter Achten, John van Groningen and Rinus Plasmeijer (1992). &#039;&#039;High-level specification of I/O in functional languages&#039;&#039;, Proc. of the Glasgow workshop on Functional programming, ed. J. Launchbury and P. Sansom, Ayr, Scotland, Springer-Verlag, Workshops in Computing, pp. 1-17.&lt;br /&gt;
* [AcP95] Peter Achten and Rinus Plasmeijer (1995). &#039;&#039;The Ins and Outs of CONCURRENT CLEAN I/O&#039;&#039;, Journal of Functional Programming, 5, 1, pp. 81-110.&lt;br /&gt;
* [AcP97] Peter Achten and Rinus Plasmeijer (1997). &#039;&#039;Interactive Functional Objects in CLEAN&#039;&#039;, Proc. of the 1997 Workshop on the Implementation of Functional Languages (IFL&#039;97), ed. K. Hammond Davie, T., and Clack, C., St.Andrews, Scotland,&lt;br /&gt;
* [VPA07] Edsko de Vries, Rinus Plasmeijer, and David M. Abrahamson, &#039;&#039;Uniqueness Typing Simplified, by Edsko de Vries&#039;&#039;,&lt;br /&gt;
* [http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf the language report] by Rinus Plasmeijer and Marko van Eekelen,&lt;br /&gt;
* [http://clean.cs.ru.nl/ the language homepage].&lt;br /&gt;
&lt;br /&gt;
===Involvement of project participants to other grants, contracts, etc …===&lt;br /&gt;
&lt;br /&gt;
* Emmanuel Chailloux is member of the ANR PWD (&amp;quot;Programmation du Web Diffus&amp;quot;), whose leader is Manuel Serrano (Inria), and the FUI [http://opengpu.net/ OpenGPU project].  &lt;br /&gt;
* Tom Hishowitz is involved in the ANR PiCoq the ANR proposals RÉCRÉ and CATHRE.&lt;br /&gt;
* Pierre Hyvernat is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Alexandre Miquel is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Christophe Raffalli is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
&lt;br /&gt;
Remark: the interaction with PML and RÉCRÉ is natural because the proof technics used for ensuring some of the properties of the language PML is realizability which is one of the théma of the ANR proposal RÉCRÉ.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5089</id>
		<title>ANR PML</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5089"/>
		<updated>2011-01-13T11:33:23Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Context and positioning of the proposal */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;URL of PML project: &amp;lt;tt&amp;gt;http://lama.univ-savoie.fr/tracpml&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Context and positioning of the proposal==&lt;br /&gt;
&lt;br /&gt;
Ever since FORTRAN appeared fifty years ago, programming languages have been evolving rapidly. These languages now include more and more sophisticated concepts like &amp;quot;objects&amp;quot;, &amp;quot;type inference&amp;quot;, &amp;quot;modules&amp;quot;... However, this richness is also what makes it more and more complex to train programmers and makes it difficult for them to keep up with the innovations and changes in programming languages.&lt;br /&gt;
&lt;br /&gt;
Another orthogonal phenomenon is the emergence of formal methods used in conjunction with various programming languages to test, check or prove software. This introduces another layer to languages in order to write specifications, and sometimes yet another one for proofs. Learning a programming language together with the associated specification/proof languages can take an important effort.&lt;br /&gt;
&lt;br /&gt;
Projects such as [http://www.cs.utexas.edu/users/moore/acl2/ ACL2], the successor of  [http://www.cs.utexas.edu/users/boyer/ftp/nqthm the Boyer-Moore theorem prover] uses a rather simple language (namely LISP) both as a programming language and specification language, allowing to keep a unity in the system. Unfortunately, LISP is somewhat limited both as a programming language (no good treatment of sum types, no module system) and a specification language (very limited quantification). Moreover, LISP has no compile-time type-checking, which has proved very useful to detect bugs and automatically assert properties.&lt;br /&gt;
&lt;br /&gt;
The aim of the present project is to build a very powerful language (with no loss of expressive power compared to state of the art languages) based on a very small number of simple features. We think this will be possible thanks to recent progress both in the semantics of programming languages and the apparition of new algorithms for type inference based on constraint-solving. In fact, we propose in [RAF10b] an innovative concept derived from the later to enable this: constraint-checking.&lt;br /&gt;
&lt;br /&gt;
Moreover, the language will be used not only as a programming language and a specification language (like in ACL2), but also as the proof language. This is natural for an ML-like language because pattern-matching is a natural and powerful way to make a proof by case analysis. This also means that our tool will consist of relatively few (unified) features, yet powerful.&lt;br /&gt;
&lt;br /&gt;
The idea of a new language arose from the discovery of a new typing algorithm [RAF10b] whose implementation gave birth to a first implementation of PML (Proved ML) by Christophe Raffalli. This implementation is already available from [http://www.lama.univ-savoie.fr/~pml the web page of the language]. However, turning PML into a real tool requires a lot of research and implementation work and this is why we request the help of the ANR. Some of the goals are highlighted in the next sections.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML approach to mathematics and program certification is unique&#039;&#039;&#039; Existing provers or certification tools feature a base programming language, and a logical layer on top of it (be it to write mathematical statements, specifications, or proofs). PML is very different in spirit: every statement, including sophisticated mathematical ones, is reduced to a statement asserting that a program fragment does not raise any error. &lt;br /&gt;
&lt;br /&gt;
PML has no dedicated proof language, but the user can still write proofs! Existing programming languages supporting specifications use one or more of the following two alternatives: automated proofs (ACL2, Why) or proof obligations, that the user can prove using a specific language (Coq extraction, Focalize, Why). Several systems provide both possibilities, manual proofs being used only when automation fails. PML is again very different: it introduces a new instruction, written with a &amp;quot;scissors symbol&amp;quot; &amp;lt;tt&amp;gt;&#039;&#039;&#039;8&amp;lt;&#039;&#039;&#039;&amp;lt;/tt&amp;gt; to express that the corresponding position in the program is &#039;&#039;dead&#039;&#039;, meaning that it can not be reached during evaluation. This condition is checked by a terminating variant of the Knuth-Bendix completion algorithm. This is rather simple and therefore easier to trust than modern decision procedures. However, it only solves trivial cases: to write complex proofs, the user just uses the same syntax as for programs to do case analysis or induction (i.e., recursive definitions). This means that the user does not need learn a specific proof language and hopefully implies that PML is easier to learn and probably more adapted to industry that previous solutions.&lt;br /&gt;
&lt;br /&gt;
The logic of PML is just the equational theory of its programming language; and we use variants of Knuth-Bendix completion as a proof-checker. The first experiments with the current implementation are promising. However, adapting the Knuth-Bendix procedure to the context of ML is a complex and new research problem. A lot more work is needed, for instance to handle proofs in arithmetic which occur quite often. Here is an example of a proof in arithmetic, checked in the current version of PML. This is not completely satisfactory (hard to write), but shows the use of the language for both proofs and programs and the use of recursive functions for inductive proofs:&lt;br /&gt;
&lt;br /&gt;
  val rec mul_associative x y z |- (x * y) * z == x * (y * z)&lt;br /&gt;
    proof match x with&lt;br /&gt;
      Z[] -&amp;gt; 8&amp;lt; (* trivial case handled automatically by Knuth-Bendix *)&lt;br /&gt;
    | S[x&#039;] -&amp;gt;&lt;br /&gt;
      let _ = mul_associative x&#039; y z in (* There is a syntactic sugar for that... *)&lt;br /&gt;
        (* this adds the fact that (x&#039;*y) * z == x&#039; * (y*z) to the environment *)&lt;br /&gt;
 &lt;br /&gt;
      let _ = mul_right_distributive y (x&#039; * y) z in&lt;br /&gt;
        (* this adds the fact that (y + x&#039;*y) * z == y*z + (x&#039;*y)*z *)&lt;br /&gt;
 &lt;br /&gt;
        (* the environment now contains enough information for Knuth Bendix to handle the rest:&lt;br /&gt;
         *    - x*(y*z)  ==  y*z + x&#039;*(y*z)  : by definition&lt;br /&gt;
         *    - x*y == y + x&#039;*y : by definition&lt;br /&gt;
         *      and so (x*y)*z == (y + x&#039;*z)*z&lt;br /&gt;
         *    - (x&#039;*y) * z == x&#039; * (y*z)  :  by the recursive call to mul_associative&lt;br /&gt;
         *    - (y + x&#039;*y) * z == y*z + (x&#039;*y)*z : by the call to mul_right_distributive  *)&lt;br /&gt;
      8&amp;lt;&lt;br /&gt;
&lt;br /&gt;
Moreover, this style of proof is declarative and relatively readable (like Mizar proofs) while concise at the same time. This is very important when you want to maintain large developments.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;PML is different from the other modern programming languages&#039;&#039;&#039; because its design focuses on a few powerful concepts. One consequence is that it is more difficult for a compiler to produce efficient code. In particular, since PML unifies several notions of products (modules, tuples and records), there is no simple way to choose the internal representation of a product, especially with implicit subtyping. Writing a good compiler for PML will thus require more complex and original optimization schemes (probably driven by typing) than for languages like OCaml or Haskell. A Polish student (Wojciech Matyjewicz) is just starting a PhD on this very topic.&lt;br /&gt;
&lt;br /&gt;
Here is a simple example, accepted by the current version of PML, demonstrating product types, sum types and subtyping. We define ternary trees as an extension of binary trees with an implicit subtyping&lt;br /&gt;
relation (all functions accepting binary_trees will accept ternary trees, by ignoring the &amp;lt;tt&amp;gt;middle_son&amp;lt;/tt&amp;gt;):&lt;br /&gt;
&lt;br /&gt;
 type rec binary_tree (A) =&lt;br /&gt;
   [ Nil[] | Node[A with left_son : binary_tree(A); right_son : binary_tree(A)] ; ]&lt;br /&gt;
 type rec ternary_tree(A) =&lt;br /&gt;
   binary_tree({ A with middle_son : ternary_tree(A) ;})&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML requires a termination criterion&#039;&#039;&#039; because a proof by induction will just be a normal recursive program. Such a program has to be well-founded in order to correspond to a valid proof. A subset of Haskell can now use the Aprove tool to establish termination for simple programs. However, we want the test to be fully integrated with the language, and be compatible with very modular programs. At the moment, these goals seem difficult to achieve with Aprove or other external termination checkers. A first termination criterion based on Lee, Jones &amp;amp; Ben-Amram&#039;s &amp;quot;size-change termination principle&amp;quot; was implemented by Pierre Hyvernat [Hyv10b]. While this test is quite powerful, it is necessarily incomplete, and quite some work is required to make termination proofs of complex programs tractable.&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical description==&lt;br /&gt;
&lt;br /&gt;
===Background, state of the art===&lt;br /&gt;
&lt;br /&gt;
====Programming language====&lt;br /&gt;
&lt;br /&gt;
The ML programming language, created by Robin Milner &amp;lt;em&amp;gt;et al&amp;lt;/em&amp;gt; in the 80&#039;s has two major distinctive features:&lt;br /&gt;
* Algebraic data-types and pattern matching: data types are basically all constructed using fixpoint, Cartesian product (product types) and disjoint union (sum types).&lt;br /&gt;
* Static type inference: the type of every piece of code is automatically inferred using Hindley-Milner algorithm (HM). By construction, once compiled, an ML program can not crash (no segmentation fault). More precisely, when we do not use unsafe features of the language (like interface with unsafe libraries written in C), if an ML program produces a segmentation fault, then there is a bug in the type-checker or the compiler.&lt;br /&gt;
&lt;br /&gt;
Recent progress in type inference algorithm uses constraint solving. This means that the type system can be described in first-order predicate logic in such a way that a type inference problem is a formula written in a decidable fragment of first-order predicate logic (often the purely existential fragment). Hence, any constraint solver can be turned into a type-checker for ML. These approach is known as HM(X) (see [SOW97]).&lt;br /&gt;
&lt;br /&gt;
There are two problems with this approach:&lt;br /&gt;
* The complexity of constraint solving can be too high for practical use, especially when using a general purpose constraint solver. To our knowledge, there are currently no mainstream implementation of ML based on HM(X).&lt;br /&gt;
* HM(X) does not completely solve the problem of subtyping. The language to express the types constructed by the constraint solver is the same as the language of types used by programmers. With constraints &amp;lt;math&amp;gt;\alpha \subseteq \beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\alpha \subseteq \gamma&amp;lt;/math&amp;gt; for three types &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\gamma&amp;lt;/math&amp;gt;, the most natural solution is &amp;lt;math&amp;gt;\alpha = \beta \cap \gamma&amp;lt;/math&amp;gt;. This implies that intersection needs to be part of the language for types. This means that constraints such as &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \delta&amp;lt;/math&amp;gt; may also appear and they are problematic to deal with. Similar reasoning shows that constraints of the form &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \beta&#039; \cup \gamma&#039;&amp;lt;/math&amp;gt; may appear, increasing the complexity of constraint solving by an exponential factor.&lt;br /&gt;
&lt;br /&gt;
PML&#039;s approach is to replace type-inference by &#039;&#039;constraint &amp;lt;u&amp;gt;checking&amp;lt;/u&amp;gt;&#039;&#039; rather than constraint solving: we only check that the constraints are satisfiable in some model. Type-checking in the current implementation of PML can be seen as a black box ensuring that nothing can go wrong during execution. Moreover, since we do not need to write solutions for the constraints, the language for types can be relatively simple. In fact, the types written by the programmer aren&#039;t even the actual type constraints that are checked: they are syntactic sugar for the partial identity on the intended type (giving for free nice feature like higher-order parametric types, that is types with parameters which may be themselves types with parameters). In other words, the expression &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; is a synonym for &amp;lt;tt&amp;gt;(id_nat x)&amp;lt;/tt&amp;gt; where&lt;br /&gt;
  val rec id_nat x = match x with&lt;br /&gt;
      Z[] -&amp;gt; Z[]&lt;br /&gt;
    | S[x&#039;] -&amp;gt; S[id_nat x&#039;]&lt;br /&gt;
is defined internally by PML. The constraints generated by &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; mean exactly that &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is of type &amp;lt;tt&amp;gt;nat&amp;lt;/tt&amp;gt;...&lt;br /&gt;
&lt;br /&gt;
With this approach, we loose type-inference and the ability to display types in error messages. Nevertheless, PML error reporting is quite helpful because, in case of problems, it displays three positions in the code and an error message like this &amp;lt;tt&amp;gt;error at position 1, label &amp;quot;id&amp;quot; projected at position 2 do not appear in the value constructed at position 3&amp;lt;/tt&amp;gt;. This kind of error message is in fact of bounded length and often more useful than OCaml or SML messages. We can understand this as showing three points in the &#039;&#039;slice&#039;&#039; of the error, as introduced by Joe Wells in [HW04].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Proof assistant====&lt;br /&gt;
&lt;br /&gt;
Proof assistants have evolved rapidly since Automath in the 70th. Two main trends coexist: automated proof assistants such as ACL2, PVS and &#039;&#039;safe&#039;&#039; ones such as Coq, Isabelle, PhoX, Lego, HOL, Matita, &amp;lt;em&amp;gt;etc.&amp;lt;/em&amp;gt; The former incorporate very sophisticated automated deduction strategies, with no &#039;&#039;certificate&#039;&#039; for the validity of the proof, while the later require all proofs to be done in a specific framework (like natural deduction or type theory) allowing for a simple check of the proof. The gap between the two approaches tend to be reduced by the emergence of complex tactics (for Coq or Isabelle mainly) which build proofs for the user. For instance Zenon is an advanced automated first-order theorem prover that outputs a Coq proof.&lt;br /&gt;
&lt;br /&gt;
The common defect of all these proof assistants is that a proof can not be written nor understood without running the proof assistant. Some proof assistants such as Mizar or Alf do not follow exactly the above scheme: Mizar has a declarative style for proof which is (in theory) readable by a human and checked by a limited checker (This proof style has been adapted to Coq and Isabelle). Unfortunately, there is no formal description of the Mizar proof checker. Alf on the other hand is based on proof theory and requires the user to basically write the complete proof tree just leaving out a few details. The logic is very well formalized and simple, but writing proof is tedious and not similar to the usual practice of informal mathematics.&lt;br /&gt;
&lt;br /&gt;
This picture of the world of proof assistants shows that some fundamental work is needed. In the current version of PML, the logic is just an equational theory of the underlying programming language. This is easily described formally. The proof engine is, like in Mizar, a limited automated checker inspired by the Knuth-Bendix completion algorithm (KB). The completion algorithm used in PML had to be adapted to the higher-order constructs of ML-like languages and restricted to ensure termination and an acceptable complexity. The current limitation is probably too strong: it is limited to closed terms and cannot use universal theorems automatically (as in the first example of section 1, where one has to give explicitly the argument to use distributivity).&lt;br /&gt;
&lt;br /&gt;
Nevertheless, preliminary examples in the current version shows that the approach is worth trying: proofs are concise and readable once you know the language. A very encouraging point is that all examples where written without interface. This really means that proofs are readable without the help of a computer.&lt;br /&gt;
&lt;br /&gt;
===Rationale highlighting the originality and novelty of the proposal===&lt;br /&gt;
&lt;br /&gt;
The final objective of our project would be a full PML compiler, bootstrapped and completely proved with itself (full bootstrap). This does not exist for any language and is far too ambitious for a four years project.  More realistically, we plan to produce a compiler for PML, written in PML, but not proved in PML yet.&lt;br /&gt;
&lt;br /&gt;
We also want to develop proof-checking in such a way as to allow very elegant proofs, supporting the feasibility of a full bootstrap by various examples, some of them being near to industrial application, some others being algorithms coming from implementation of programming languages.&lt;br /&gt;
&lt;br /&gt;
We have focused the existing development on the quality of the language both for proofs and programs. By quality, we mean easy to understand and write (and therefore, easy to learn). We think that using the programming language as a proof language could make formal methods more attractive to the industry without the defect of systems like PVS and ACL2 where the automated tactics replace the need for a proof language, but are sometimes hard to control and use. For instance, finding the right &#039;&#039;lemmas&#039;&#039; to make a proof possible in ACL2 is quite difficult.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other proof systems devoted to programming.&#039;&#039;&#039; Many other proof systems have been used or specifically developed&lt;br /&gt;
to allow the production of certified code: extraction in Coq, Why with its automated prover Who from the Proval project, Focalize, PVS, ATS, ... None of these system uses the programming language as a proof language. They all have a dedicated language for proofs and even if some of them like Focalize or Coq extraction using a Mizar style mode for proof, have readable proofs, learning the proof language is never trivial. Other systems like PVS, ATS, Why using Who rely on automated deduction. In those cases, the behavior of the automated prover is always hard to predict.&lt;br /&gt;
&lt;br /&gt;
Another selling point is that the logic and programming language are fully integrated. This is not a two level systems like most systems (but not all, ACL2 for instance is fully integrated). In PML, the statements of theorems and their proofs are expressions at the same level than programs. This means that a program can contain specifications that contains themselves program definitions in their statement or proof and so on. This is generally not possible (even in ACL2) and makes it possible to write modules with their specifications.&lt;br /&gt;
&lt;br /&gt;
One of the key idea for this project is that any ML-like programming language has all the features needed for a proof language: case analysis via pattern matching and exception handling, induction, calling previously defined program/theorems. This means that it is natural to explore this direction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other programming languages&#039;&#039;&#039;. Another key idea in PML is to develop the language and its proof-checker together. This has a great impact on the design of PML. Let&#039;s illustrate this with a concrete example: exception handling. In ML, there is a construct&lt;br /&gt;
  try P with e -&amp;gt; R&lt;br /&gt;
but, this is not sufficient to do case analysis on the fact that a program &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises or not an exception. In particular, &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; can be the proof just in case &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises an exception. However there is no place holder for the normal case (without exception). This is why we had to introduce a&lt;br /&gt;
  let try x = P in Q with e -&amp;gt; R&lt;br /&gt;
where &amp;lt;tt&amp;gt;Q&amp;lt;/tt&amp;gt; is evaluated only when &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; reduces to a value.&lt;br /&gt;
&lt;br /&gt;
A great number of decisions on the language design comes from the interaction between the development of the programming language and its proof-checker. Another key feature of PML, which makes the project original even as a programming language compared to many other projects of programming language research (GALLIUM, Haskell, Scala, ...) is the use of constraint checking. This choice arises from the fact that we want a language as small as possible, because a proof-checker is complex and therefore, we want to fully unify all sorts of Cartesian product including modules, records, tuples and variant with multiple argument. This is already achieved in the current implementation of PML and to my knowledge, no ML like language have a unique but still powerful notion of Cartesian product.&lt;br /&gt;
&lt;br /&gt;
All the systems previously mentioned allow to prove programs in limited subsets of existing languages like ML or Haskell. The prover has to find ways to deal with those languages&#039; defects rather than improve them...&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical program, project management==&lt;br /&gt;
&lt;br /&gt;
===Specific aims of the proposal===&lt;br /&gt;
&lt;br /&gt;
As said in the previous section, the final objective would be to have a fully bootstrapped PML language: this would mean that PML is entirely written and proved in PML. This would be too ambitious at first, and we chose to focus here on the design of the language plus a proof of concept, that is compilation and proof of various examples, searching to do our best on the following points:&lt;br /&gt;
&lt;br /&gt;
* Natural way of writing programs (Task 1)&lt;br /&gt;
* Efficiency of the code generated by the compiler, despite the heavily use of subtyping (Task 3)&lt;br /&gt;
* Readable and short proofs (Task 1, Task 4)&lt;br /&gt;
* Efficiency of type-checking and compilation (Task 2 and 6)&lt;br /&gt;
* Efficiency of proof-checking (Task 4 and 6)&lt;br /&gt;
* All of the above points need testing, and we created a transverse fifth task for that.&lt;br /&gt;
&lt;br /&gt;
===Project management===&lt;br /&gt;
&lt;br /&gt;
We plan to have one 3 days workshop per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems. We already have the agreement of some people to participate in such meetings: Joe Wells, Assia Mahbouby, Andreas Abel, ...&lt;br /&gt;
We plan to have one 3 days meetings per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems.&lt;br /&gt;
&lt;br /&gt;
We will also organize two project meetings per year, just to keep track of progress, share idea and organize the above workshops and other invitations.&lt;br /&gt;
&lt;br /&gt;
We want also to organize visits of one or two members of the project to visit researchers on similar topic (typically a member of the project could visit one of the invited speaker of our workshop). Members of the project should also travel to conference on the subject like POPL, LICS, CSL, TYPES or the recently created CPP (first conference in 2011).&lt;br /&gt;
&lt;br /&gt;
===Detailed description of the work organized by tasks===&lt;br /&gt;
&lt;br /&gt;
====Task 1 - theoretical work, design of the language ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Alexandre Miquel, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.a - Correctness of the constraint checking algorithm&#039;&#039;&#039; (delivered&lt;br /&gt;
09/2012): [RAF10b] already cover the correctness without polymorphism. A draft version of &lt;br /&gt;
the correctness proof with polymorphism does exist but needs more work. The &lt;br /&gt;
main open problem here is the interaction with the termination-check. The current work &lt;br /&gt;
proves that when constraints are checked, the program can only loop via recursive definitions.&lt;br /&gt;
Then, we would like to prove that the program is terminating if recursive definitions are accepted by the &lt;br /&gt;
termination checker. However, this is non trivial.&lt;br /&gt;
&lt;br /&gt;
This being a central piece of PML, it should be also one&lt;br /&gt;
of the first tests for PML in task 5. We could also prove this part of PML in&lt;br /&gt;
Coq (in fact 2 provers proving themselves and each other correct is a much&lt;br /&gt;
stronger warranty than one prover proving itself).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.b - Consistency of proof-checking&#039;&#039;&#039; (beginning 09/2011, delivered before 09/2013 for the core of the language): This is essential for clearly defining the logic of PML and prove its consistency. This should not be too hard for the core of the language. However, this proof has to be extended to take into account all future extensions of the language and could be seen as a &#039;&#039;permanent task&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.c - Adaptation of uniqueness typing to the context of constraint checking&#039;&#039;&#039; (beginning 09/2012, delivered 01/2014): The current version of PML is a pure functional programming language, with no imperative feature. This is problematic, because input/output is necessary for real programs and affectations are required for efficiency especially when using large arrays. We plan to adapt the approach of the [http://clean.cs.ru.nl/ Clean language] [AGR92], [AcP95], [AcP97], [VPA07]. In Clean, all programs can be analyzed as purely functional programs, but the type system can check that some data are not used any more and reuse the place in memory for other data (allowing affectation). For instance, in such a context writing in a file &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; can be written as &amp;lt;tt&amp;gt;let f&#039; = write f str in ...&amp;lt;/tt&amp;gt;, but the compiler must check that &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; will not be used anymore implying the equivalence between the standard imperative semantics of writing to file and the purely functional semantics used by proofs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.d - Private, abstract and existential types.&#039;&#039;&#039; (beginning 09/2011, delivered&lt;br /&gt;
09/2012 for private type, beginning 09/2012, delivered&lt;br /&gt;
09/2013 for existential types and beginning 09/2013, delivered 09/2015 for abstract&lt;br /&gt;
types)&lt;br /&gt;
 &lt;br /&gt;
Abstract data types hide the definition of a data type and allow the user of&lt;br /&gt;
a library to be sure that his code will continue to work even if the internal&lt;br /&gt;
representation of data are changed. In the context of constraint-checking in&lt;br /&gt;
PML, adding abstract data types seems to be a challenging task. Moreover,&lt;br /&gt;
abstract data-types are a form of existential quantification over types and&lt;br /&gt;
could raise some consistency issues. We hope to find a way to incorporate&lt;br /&gt;
abstract types in PML without loosing coherence.&lt;br /&gt;
 &lt;br /&gt;
A first step would be private data types. They are a very simple yet very powerful mechanism for easily&lt;br /&gt;
ensuring invariants on all values of a data type. This mechanism is as&lt;br /&gt;
follows: the compiler simply checks that the constructors of a data type are&lt;br /&gt;
not used for constructing values. Values are constructed by using construction&lt;br /&gt;
functions, like with abstract data types. However, unlike with abstract data&lt;br /&gt;
types, constructors can still be used as patterns for defining functions by&lt;br /&gt;
pattern-matching. Hence, a library on a private data type is not closed but&lt;br /&gt;
can be extended easily. Private data types are therefore an important and very&lt;br /&gt;
useful feature for defining data structures with complex invariants and&lt;br /&gt;
proving their correctness more easily. They have been implemented in OCaml by&lt;br /&gt;
Pierre Weis and are described in Frédéric Blanqui, Thérèse Hardin and Pierre&lt;br /&gt;
Weis&#039; ESOP&#039;07 paper [BHW07].&lt;br /&gt;
&lt;br /&gt;
A second step would be existential types, which are very similar to abstract types,&lt;br /&gt;
but with no free name for the abstract type. On a logical level, they do imply an existential quantification over types&lt;br /&gt;
which has to be limited to ensure consistency. However existential types do not require the type to have a free name, which corresponds in logic to a definite description operator (similar to Hilbert&#039;s epsilon operator), and this, being connected to the axiom of choice (over types), may be really problematic for consistency. Some work related to this exists in the phd thesis of F. Ruyer, a former student of C. Raffalli [Ruy06].&lt;br /&gt;
&lt;br /&gt;
====Task 2 - termination====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Pierre Hyvernat&lt;br /&gt;
&lt;br /&gt;
Participants: Christophe Raffalli, Andreas Abel, Frederic Blanqui&lt;br /&gt;
&lt;br /&gt;
Remark: this is an essential task, running during the 4 years. There will always be some embarrassing examples that do not work, but could work... both for the core and auxiliary criterion (see below for the distinction) meaning that this research field will remain open forever.&lt;br /&gt;
&lt;br /&gt;
Even if it might be counter-intuitive at first, it is often necessary to write programs whose execution can be infinite. For example, any kind of &amp;quot;server&amp;quot;, or almost any interactive program might have infinite executions. Even in purely mathematical setting, it can be interesting to have intermediary non-terminating functions. Consider a function outputting the stream of prime numbers : even if this function is non-terminating, we might use it in a terminating manner in a proof by requesting the &#039;&#039;n&#039;&#039; first prime numbers.&lt;br /&gt;
&lt;br /&gt;
Since PML uses full recursion (keyword &amp;lt;tt&amp;gt;rec&amp;lt;/tt&amp;gt;), writing such programs is easy. On the other hand, the notion of &amp;quot;terminating&amp;quot;, or &amp;quot;well-founded&amp;quot; recursive function isn&#039;t part of the core of PML: such programs are just special cases of recursive programs. The user will have to specify which functions are in fact terminating and might have to prove it himself when PML cannot infer termination automatically.&lt;br /&gt;
&lt;br /&gt;
Proofs of specifications are just PML programs, and those cannot be allowed to run infinitely. More precisely, even if proof will never be run at all (no computational content), they are required to be well-founded. The consistency of PML relies on this. In order to relieve the user from proving that all proofs are in fact terminating, PML should offer a way to check automatically that (some) functions are terminating. Because the halting problem is undecidable, it is hopeless to do that in all generality, but this is seldom necessary: many proofs terminate for obvious reasons. PML should only work for most of the functions, most of the time (rather than work for all the functions, all the time...)&lt;br /&gt;
&lt;br /&gt;
Technically speaking, PML can infer an error called &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; when it encounters a program which, it thinks, may not terminate. Such an error cannot be captured: this is an error rather than an exception. The property we need to guarantee is that if PML doesn&#039;t infer the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; possible, then the program in question does indeed terminate. If the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; is possible for a terminating function, the user can still provide PML with a proof that this error is never raised. PML current syntax for that is &amp;lt;tt&amp;gt;[p proof ... ]&amp;lt;/tt&amp;gt; where &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; is a term and &amp;lt;tt&amp;gt;...&amp;lt;/tt&amp;gt; is a proof that &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; doesn&#039;t raise any exception nor error (this is the desired property for proofs).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.a - Core termination criterion&#039;&#039;&#039; (delivered 09/2010)&lt;br /&gt;
&lt;br /&gt;
This first test is now part of PML. Since primitive recursive function isn&#039;t enough in practice, even for proofs, a subtler and more powerful termination criterion has been implemented. This is an extension of the &amp;quot;size change principle&amp;quot; of Lee, Jones and Ben-Amram [LJ01]. This test successfully checks termination for primitive recursion, lexicographic ordering and permutation of arguments and thus covers most simple practical cases. The implementation is quite similar to the original size-change principle, but the proof of correctness is surprisingly more difficult: see [Hyv10b].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.b - Improvement of the core termination criterion&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
The size-change principle is simple and powerful, but many cases occurring in practice aren&#039;t tagged as terminating. We plan to adapt to PML a termination criterion based on the technique of type-based termination, which allow for recursive calls through size preserving functions such as &amp;lt;tt&amp;gt;List.map&amp;lt;/tt&amp;gt;. There are several possibilities, ranging from simple systems such as the one developed by Abel (RAIRO&#039;04) [Abel04], Barthe et al (MSCS&#039;04) [Bar04] or Blanqui (RTA&#039;04, CSL&#039;05) [Bla04, Bla05c], to the very rich system of Blanqui and Riba (LPAR&#039;06) [BlR06]. In the latter, given for each function some formula in Presburger arithmetic describing how the size of the output is related to the size of the inputs (the correctness of which can be checked automatically), the termination follows from the fact that recursive calls are done on strictly decreasing arguments, using for instance lexicographic or multiset comparisons together with linear combinations of the arguments. Intermediate systems, such as the one of Barthe, Grégoire and Riba (CSL&#039;08) [BGR08] which is powerful but with a lower complexity than Presburger arithmetic, have also to be considered.&lt;br /&gt;
&lt;br /&gt;
This development looks rather orthogonal to the implemented criterion and might require small modification of other parts of PML in order to get the appropriate information. On a different level, slight extensions should be added to the existing criterion to enhance its complexity on some specific examples that are recognized as termination, but not in a reasonable time.&lt;br /&gt;
&lt;br /&gt;
This core termination needs to reach an acceptable compromise between power and simplicity. In particular, the most complex developments may not find their way into the core termination criteria, but rather be used in the next task...&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.c - Use of external provers&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
In order to circumvent the limitations of the core termination criterion, we propose to use external powerful termination provers like [http://aprove.informatik.rwth-aachen.de/ Aprove] or [http://colo6-c703.uibk.ac.at/ttt2/ TTT2] that implement and combine many other termination techniques. To this end, we can define translations from PML programs to one or more of the possible formats currently used in the [http://termination-portal.org/wiki/Termination_Competition annual international competition on termination] and in particular: first-order rewrite systems (TRS), dependency pair problems (DP problem), higher-order rewrite systems (HOTRS) or Haskell programs. In particular, we could reuse some of the techniques used for converting Haskell programs into first-order DP problems in [Gie06].&lt;br /&gt;
&lt;br /&gt;
But to which extent can we trust the results of these provers? Hopefully, now, many termination provers provide certificates in a format called [http://cl-informatik.uibk.ac.at/software/cpf/ CPF] that can be checked by certified, dedicated tools like [http://cl-informatik.uibk.ac.at/software/ceta/ CeTA], [http://color.inria.fr/ Rainbow] or [http://a3pat.ensiie.fr/ CiME3].&lt;br /&gt;
&lt;br /&gt;
The most pragmatic route is simply to trust those tools and concentrate on proving that the translation from (restricted) PML code to the input language is indeed correct. Of course, the ideal solution would be to be able to translate the external certificates into an equivalent PML program whose termination can be infered by the core criterion. The complexity of tools like [http://aprove.informatik.rwth-aachen.de/ Aprove] makes it look very difficult and it is probably hopeless to do that in a general manner.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.d - Modularity and termination&#039;&#039;&#039; (beginning 09/2013, never ending)&lt;br /&gt;
&lt;br /&gt;
The core termination prover does not use the definition of functions to prove their termination, but only information gathered from the typing constraints. When using external prover, for large development, one also would like to avoid sending a large piece of code to the external prover. &lt;br /&gt;
&lt;br /&gt;
Function such as &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; preserves the length of list. But the notion of length does not appear explcitely in the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. This means that the current core termination prover often can not prove termination of a function that use &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. It also means that you need to give the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; to an external tool. &lt;br /&gt;
&lt;br /&gt;
We would like to automatically compute some concise information about the size differences between input and output of program. This means that we would like to infer (when possible) a notion of &#039;&#039;size&#039;&#039; from the definition of a function.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Remark&#039;&#039;&#039;: The halting problem is undecidable, the available external tools for checking termination are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the termination checker.&lt;br /&gt;
&lt;br /&gt;
====Task 3 - compilation ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Wojciech Matyjewicz, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.a - A first compiler using LLVM&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012) LLVM is a compiler infrastructure providing many tools: compilation strategy, virtual instruction set, compiler infrastructure, tools to write high level virtual machines, etc. LLVM is very attractive, because it is rather simple to use (it even has an OCaml interface) and can compile for a bytecode interpreter, can be used as a JIT compiler or a standard compiler. Moreover, it support a lot of platforms. It also provide some optimizations, which is important. We think that writing a compiler, with no optimization, for PML using LLVM should not be too hard (this is important that this task be easy, because this is not really research ...)&lt;br /&gt;
&lt;br /&gt;
A polish phd student Wojciech Matyjewicz has started to work on this in December. He visited the LAMA during one week to start the project. It is important to note that he is a first year phd in Poland and the first year there is equivalent to our Master 2. Which means that Wojciech Matyjewicz is a potential candidate.&lt;br /&gt;
&lt;br /&gt;
Then, we would like to improve our compiler in various direction. We mention here the ones that are innovative in this domain (we should also consider more standard optimization, but we do not mention them specifically). &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.b - Representation of cartesian product and disjoint sum&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012 for product) PML allows only one kind of cartesian product which in general (because of multiple inheritance and implicit subtyping) must be represented as a table (hash-table or maps based on binary search trees). These can impact performance. We plan to generate extra constraints for each occurrence of a constructor of a cartesian product in a program. Then, solving this constraint in a way that maximize speed (or size) should allow for a representation of cartesian product that is more efficient than using, for instance, OCaml. The same kind of optimization (with a different optimization criterion) should be done for sum types and the implementation of pattern matching. This optimization should be included in the first compiler because the implantation with tables is too costly for a temporary solution.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.c - Unboxing&#039;&#039;&#039; (depends on some parts of 3.b, beginning 1/2012, delivered 1/2013) In general, 32 bits integer and floating point number are boxed (that is represented by a pointer). This allows a more elegant language. This can lead to major impact on performance especially when arrays are involved. We think that constraint-checking is a good framework to propagate type information and allow efficient unboxing. Nevertheless, doing enough unboxing to try to match the performance of low level languages like C is very hard. We hope that we can reuse some of the work of task 3.b, because unboxing can be seen also as the optimization of the representation of a cartesian product with only one field.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.d - compilation of affectation (reference and arrays) and IO&#039;&#039;&#039; (depend upon 1.c, beginning 09/2012, delivered 03/2014) After adapting uniqueness typing to PML (task 1.c), we will be able to compile affectation and IO imperatively as in any imperative programming language.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.e - Garbage collection&#039;&#039;&#039; (beginning 01/2014, delivered 09/2014) For simplicity reasons, the first compiler will simply use Boehm&#039;s garbage collector. This garbage collector is relatively efficient and simple to use. However, Boehm&#039;s GC isn&#039;t optimized for the kind of allocations used in a functional language. Moreover, having a multithreaded GC could prove useful in moder environment. We thus plan to replace Boehm&#039;s GC by a dedicated GC tuned for our purposes.&lt;br /&gt;
&lt;br /&gt;
Writing a GC that is both efficient and correct is not easy, and this sub-task is rather orthogonal to the PML language, which explains why it only comes later during the project. Nevertheless, we feel it is necessary to go through the trouble if we want to be as efficient (or even better, more efficient) than existing functional languages...&lt;br /&gt;
&lt;br /&gt;
====Task 4 - Automated reasoning====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Frédéric Blanqui&lt;br /&gt;
&lt;br /&gt;
Participants: Frédéric Blanqui, Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
The kernel of the proof engine will be based on completion techniques. Knuth-Bendix completion tries to transform a set of unoriented equations into a set of (inter-reduced and) convergent, that is, terminating and confluent, set of rewrite rules. It can therefore be used for proving that some equality is the equational consequence of some equational theory. Indeed, when an equational theory can be completed into a convergent rewrite system, two terms are equivalent in this equational theory if their normal form in the convergent rewrite systems are equal.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.a - Adaptation of the Knuth-Bendix completion algorithm to PML&#039;&#039;&#039; (already started, delivered 09/2015) As explained just before, Knuth-Bendix completion is based on rewriting. However, in PML, programs are not rewriting systems. We therefore need to adapt Knuth-Bendix completion. We need both generalization, to use the notion of constructor present in ML and take care of the higher-order nature of ML (even if we can not hope much here).&lt;br /&gt;
As said above, something is already implemented, but it is trivial because completely restricted to closed terms. A first version should be able at least to rewrite a closed term modulo some simple equational (and universal) theory. An important point here is to ensure termination&lt;br /&gt;
of this algorithm and even a low complexity. The price to pay, will be incompleteness. A lot of care should also be devoted to the correctness of the implementation, because like for task 3.a, the consistency of PML relies on it.&lt;br /&gt;
&lt;br /&gt;
This task in one of the major task for PML and a first version already exists, but is non terminating in presence of equalities between functions: if we have an equation like &#039;&#039;f = f o f&#039;&#039;, PML may use this equation has a definition of &#039;&#039;f&#039;&#039; and loop. For dealing with these cases, we are considering a fix which involves some notions similar to those of &#039;&#039;geometry of interaction&#039;&#039;. Another particular and very important case of universal equation that we should take into account is associativity and commutativity. It is indeed very important to ease proofs on integers (addition and multiplication are associative and commutative). To this end, we could reuse the [http://cime.lri.fr CiME] library.&lt;br /&gt;
&lt;br /&gt;
Note that this work could benefit to other projects and tools, like [http://moca.inria.fr/ Moca], a generator of construction functions for private data types with algebraic invariants, also based on completion, or Europa, a proof assistant based on the lambda-pi-calculus modulo rewriting developed by Gilles Dowek and [http://www.lix.polytechnique.fr/Labo/Mathieu.Boespflug/ Mathieu Boespflug]. Indeed, currently, Moca generates OCaml code without guarantee on its correctness. Using PML instead, Moca could also generate a proof of the correctness of the generated construction functions.&lt;br /&gt;
Then, later, when trying to prove the correctness of a function defined on this private date type, one can use the invariants satisfied by the values of the private data type as assumptions, since these invariants are satisfied by construction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.b - Use of external provers&#039;&#039;&#039; (beginning 03/2012, delivered 09/2015) Like for termination proofs, in order to increase the proving capacities of PML, we will provide a translation of PML proof goals into the [http://www.cs.miami.edu/~tptp/ TPTP standard format] of the CASC competition in order to be able to use external provers too, and in particular provers based on completion like [http://www.waldmeister.org/ Waldmeister], [http://cime.lri.fr/ CiME] or [http://cl-informatik.uibk.ac.at/mkbtt/ mkbTT] but not only. And possibly some certifying provers like [http://focal.inria.fr/zenon/ Zenon] based on tableaux or [http://alt-ergo.lri.fr/ Alter-Ego] based on SMT (SAT solver modulo theory).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Same remark than for termination&#039;&#039;&#039;: The problem is undecidable, the available external tools for automated reasonning are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the automated reasonning.&lt;br /&gt;
&lt;br /&gt;
====Task 5 - validation (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Christophe Mouilleron, Tom Hirschowitz.&lt;br /&gt;
&lt;br /&gt;
The validation requires to write numerous examples to check that we fulfill our main goal, which is that all programs (with or without proof) are written in the best possible way. This work being research, we think that it is important that any piece of code written in PML that does not look &#039;&#039;right&#039;&#039; is carefully examined to check that this is not due to a defect in language design.&lt;br /&gt;
&lt;br /&gt;
Christophe Mouilleron and Erik Martin-Dorel started to work on the axiomatization of computer arithmetics within an ongoing PEPS project. This is a good test for PML and moreover a requirement &lt;br /&gt;
because we want PML to be a real programming language and therefore the limited arithmetic of processors (32 and 64 bits integer and floating point number) must be supported by PML. However, proving software using them is not trivial at all and Christophe Mouilleron member of the Arénaire team in ENS Lyon is a specialist in this domain.&lt;br /&gt;
&lt;br /&gt;
Tom Hirschowitz and Christophe Raffalli already started (and almost finished) a proof in PML that &lt;br /&gt;
categories, functors and natural transformations form a 2-category (this development is available in the example directory in the current version of PML). We plan to continue such abstract developments and we think that they could lead to interesting perspectives about the modularity of PML.&lt;br /&gt;
&lt;br /&gt;
More general code, including a standard library and some significant mathematics should be developed (there is already around 10.000 lines of PML code in the current distribution). Moreover, we started to port Pierce et al.&#039;s course, in Coq, on software foundations (http://www.cis.upenn.edu/~bcpierce/sf/), to PML. The first three files are translated and there remain a dozen of files of around 2500 lines to translate. This is a major work, but would provide a very good test for PML, and a good tutorial.&lt;br /&gt;
&lt;br /&gt;
This task should deliver at least 100.000 lines of PML code to have&lt;br /&gt;
a sufficient corpus to say in which respect we fulfilled our goals.&lt;br /&gt;
&lt;br /&gt;
==== Task 6 - Optimization of PML (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: C. Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: All (anyone could optimize the part of PML he was involved in).&lt;br /&gt;
&lt;br /&gt;
Some of the choice in the design of PML involve rather complex algorithm. Notably, this is the case of the constraint checking algorithm and completion procedure. The first implementation is not trivial but not optimized either. And very often, we have discoverd and will continue to discover that PML is too slow. This goal of this transversal task is to ensure that PML is usable. &lt;br /&gt;
&lt;br /&gt;
Currently, some optimisations were already added. For instance, PML uses a sat solver for various &lt;br /&gt;
tasks: completeness and usefulness of cases in pattern matching and dealing with negative &lt;br /&gt;
hypothesis (like &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is not equal to &amp;lt;tt&amp;gt;S[x]&amp;lt;/tt&amp;gt;) in the completion procedure. Improving the sat solver using J.C. Filliâtre work [] and simplifying the formula before giving them to the sat solver were a major improvement.&lt;br /&gt;
&lt;br /&gt;
A lot of other optimisations are planned: &lt;br /&gt;
* The graph used to encode the typing constraints should probably be reduced (that is we should compute its transitive reduction). &lt;br /&gt;
* The completion procedure stores a set of terms of the language and we need a fast way to recover the set of all term using a given sub-term. The current implementation is too naive. &lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
=== Planning of tasks, deliverables and milestones ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The following diagram represents the summary of the tasks and subtasks, together with the intended planning:&lt;br /&gt;
&lt;br /&gt;
[[Image:pml-gantt.png]]&lt;br /&gt;
&lt;br /&gt;
==Data management, data sharing, intellectual property and results exploitation==&lt;br /&gt;
&lt;br /&gt;
Results in each of the tasks will be published in journals (APAL, TCS, ...) and international conferences as usual (LICS, TLCA, CSL, CIE, ...).&lt;br /&gt;
&lt;br /&gt;
PML language is already distributed as open source software under the Cecill-B license. We think that for such a research platform, this is the only possible way to ensure that people will try it. As soon as a first compiler is available, we plan to produce easy-to-install packages, at least for some well-known Linux distributions (Debian and its derivatives seem a good choice).&lt;br /&gt;
&lt;br /&gt;
==Consortium organization and description==&lt;br /&gt;
&lt;br /&gt;
===Relevance of the partner for the project===&lt;br /&gt;
&lt;br /&gt;
This project involve only one partner, the LAMA (UMR 5127), where the coordinator of the project already developed the proof assistant PhoX. The main characteristic of PhoX is to be rather simple to use due to a set of tactics which is limited (less than 20 for the principal ones), but powerful. Moreover, tactics are extensible by &#039;&#039;incorporating theorems&#039;&#039; inside the tactics.&lt;br /&gt;
&lt;br /&gt;
Clearly, this means that efficiency was the main goal of PhoX. Unfortunately, like all tactical theorem prover, PhoX proofs are not readable. After a few attempts with a Mizar-like mode for PhoX, Christophe Raffalli decided to move to a new theorem prover, starting from scratch.&lt;br /&gt;
&lt;br /&gt;
Pierre Hyvernat is also in Chambery and the second developer of PML (he wrote the current termination checker). Tom Hirshowitz has some prior experience in his phd about the compilation of functional languages. At ENS Lyon, which is very near to Chambéry, Alexandre Miquel is a specialist of consistency proof for logical framework. Therefore, Chambery is the very natural partner for this project.&lt;br /&gt;
&lt;br /&gt;
===Qualification of the project coordinator and members===&lt;br /&gt;
&lt;br /&gt;
The coordinator and various members of the project comes from various horizon (see section 7), but they have a common background around the use and development of programming language and/or formal methods. We think that this variety, the small number of members, should allow for good communication and should be very fruitful. &lt;br /&gt;
&lt;br /&gt;
We think, that compared with the development of PML by Christophe Raffalli alone, such a team should speed up the development of PML approximately by a factor 3, making it possible to deliver a very innovative and useful tool at the end of the project. The lack of support for such a team would certainly limit the tool to an experimental toy with many development only partially (or even not at all) integrated in the project.&lt;br /&gt;
&lt;br /&gt;
Christophe Raffalli will also ask for delegations during the project to be able to spend even more time on it.&lt;br /&gt;
&lt;br /&gt;
==Scientific justification of requested budget==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Meetings (total 9720€ per year)====&lt;br /&gt;
 &lt;br /&gt;
Two meetings and one workshop per year, 3 days each, for 7 people. Each meeting costs&lt;br /&gt;
1 train ticket in France, 3 days and 2 nights:&lt;br /&gt;
3*7*(100 + 3*20 + 2*80) = 6720€. &lt;br /&gt;
&lt;br /&gt;
For the workshop, we have to invite 2 to 3 guests. Some may come from foreign country and we estimate the cost&lt;br /&gt;
to 3000€ per year. Which mean a total of 9720€ per year.&lt;br /&gt;
&lt;br /&gt;
====Visits (total 10000€)====&lt;br /&gt;
&lt;br /&gt;
We think that this is very important for this project to interact with other project.&lt;br /&gt;
For instance, Andreas Abel came to visit Chambéry in 2010 for two weeks financed by our PEPS&lt;br /&gt;
project and during this time induced an important bootstrap to the implementation of the termination checker &lt;br /&gt;
[Hyv10b] and contributed a non trivial example with a proved implantation of left-leaning red-black trees.&lt;br /&gt;
&lt;br /&gt;
We want to continue such interaction. Andreas Abel already agreed as well as Joe Wells for discusion about error reporting and , Assia Mahboubi for complex proofs involving the reflexion principle. Many other discussion would be profitable about PML runtime (with multithreading ?), interaction with external tools (termination checker or automated theorem prover), &lt;br /&gt;
uniqueness typing (meeting with people already using such technics), ...&lt;br /&gt;
&lt;br /&gt;
We plan around 4 short visits of one or two weeks from people outside the project to Chambéry and the same amount for short visit in the other direction. This means around 12 weeks per year with 8 travels for a cost of 500€ per week (x12) plus in average (depending if we use plane or train) the same amount for each travel (x8), with a total of 10000€ per year.&lt;br /&gt;
&lt;br /&gt;
====Conferences (total 9600€ per year)====&lt;br /&gt;
 &lt;br /&gt;
The members of the ANR will submit papers to international conferences and&lt;br /&gt;
journals and attend to specialized workshop. We have 2.5 person/year on the project with means &lt;br /&gt;
around 3 international conferences or workshop per year (estimated cost 2000€) and one national conference or workshop per year (estimated cost 1200€)&lt;br /&gt;
&lt;br /&gt;
====Master internships (total 1500€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We plan to host around four master internships in good conditions (possibly&lt;br /&gt;
followed by PhD studentships not financed by the ANR): one per year with a total cost of&lt;br /&gt;
6000€ (1500€ each: 300€ for travel and 200€ per month for an accommodation at&lt;br /&gt;
the CROUS).&lt;br /&gt;
&lt;br /&gt;
====Computers (total 2000€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We consider that the ANR project has to participate in the renewal of the&lt;br /&gt;
computers of its participants. The lifetime of a computer being 4 years and&lt;br /&gt;
the total number of month for permanent members of the project being 112, we&lt;br /&gt;
think that we should pay for 4 computers with an average value of 2000€ each&lt;br /&gt;
(we need powerful computers and laptops, because automated reasoning requires&lt;br /&gt;
a lot of computations and memory).&lt;br /&gt;
&lt;br /&gt;
====Human resources financed by the ANR (1 PhD student, 2 two years postdocs and 4 month of invited professor)====&lt;br /&gt;
 &lt;br /&gt;
This project involves many tasks and 7 members. However, all members&lt;br /&gt;
apart from the coordinator and Pierre Hyvernat can only devote 2-3 month per year to this project&lt;br /&gt;
(they are involved in other ongoing research). Although this is far from&lt;br /&gt;
negligible, we think that we will need more human power: we estimate that 1&lt;br /&gt;
PhD and 2 postdocs are reasonable. &lt;br /&gt;
&lt;br /&gt;
We also consider that one year post-doc are not sufficient, because the time need to &lt;br /&gt;
understand the existing code base is long and the student has both to write code and &lt;br /&gt;
publish its result. Moreover, the code produced by the student will not be an experimental&lt;br /&gt;
code to support its publication, but code which should remain in the project and be maintened by &lt;br /&gt;
other member of the project. In one year, this seems impossible to achieve.&lt;br /&gt;
&lt;br /&gt;
Moreover, as mentioned in the section about visits, we would like to have 1 month per year of invited professor.&lt;br /&gt;
&lt;br /&gt;
This would give a total 88 months (4 month invited, 36 for the PhD and 48 for the 2 postdocs)&lt;br /&gt;
To be compared with the total of 104/112 month not payed by the ANR. We consider that this is a good balance.&lt;br /&gt;
&lt;br /&gt;
The total cost is 308589€.&lt;br /&gt;
&lt;br /&gt;
====Human resources not financed by the ANR====&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! month/year&lt;br /&gt;
! percentage&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Raffalli&lt;br /&gt;
| 10&lt;br /&gt;
| 85%&lt;br /&gt;
|-&lt;br /&gt;
| Frédéric Blanqui&lt;br /&gt;
| 4&lt;br /&gt;
| 25%&lt;br /&gt;
|-&lt;br /&gt;
| Emmanuel Chailloux&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Tom Hirshowitz&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Pierre Hyvernat&lt;br /&gt;
| 6&lt;br /&gt;
| 50%&lt;br /&gt;
|-&lt;br /&gt;
| Alexandre Miquel&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Mouilleron&lt;br /&gt;
| 0/2&lt;br /&gt;
| 0/15%&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total per year&#039;&#039;&#039;&lt;br /&gt;
| 26/28&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total for 4 year&#039;&#039;&#039;&lt;br /&gt;
| 104/112&lt;br /&gt;
| &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Remark: the situation of Christophe Mouilleron is unknown next year. If it is possible he will &lt;br /&gt;
continue is work on PML started with the PEPS for around 2 month per year. But if it is not possible, &lt;br /&gt;
or if he is selected for the post-doc position, then we should not count it. We used the worst case&lt;br /&gt;
on the website.&lt;br /&gt;
&lt;br /&gt;
The total cost is 350333€, ignoring Christophe Mouilleron.&lt;br /&gt;
&lt;br /&gt;
==Annexes==&lt;br /&gt;
&lt;br /&gt;
===CV, Resume of all project members===&lt;br /&gt;
&lt;br /&gt;
==== Christophe Raffalli (project coordinator) ====&lt;br /&gt;
&lt;br /&gt;
Age 41, MCF at the LAMA (UMR 5127) since September 1997.&lt;br /&gt;
&lt;br /&gt;
After his PhD in Paris VII (defended in February 1994), Christophe Raffalli spent 1 and a half year at the LFCS in Edinburgh, 2 years at Chalmers university in Göteborg (post-doc of the TYPES European project) and 1 year as ATER in Créteil University.&lt;br /&gt;
&lt;br /&gt;
Research administration: For ten years, the LAMA was sub-site of the Paris VII site inside the TYPES project which was renewed several times and Christophe Raffalli was the coordinator for this sub-site. Currently the project is not financed by the E.U. Nevertheless, Christophe Raffalli is in charge of the organization of the next TYPES meeting in Aussois in May 2009.&lt;br /&gt;
&lt;br /&gt;
His research interests include:&lt;br /&gt;
&lt;br /&gt;
* theory and implementation of proof assistants,&lt;br /&gt;
* proof theory,&lt;br /&gt;
* implementation of programming languages (especially type-systems).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Raf10b] &#039;&#039;Realizability for programming languages&#039;&#039; (submitted, available as hal-00474043)&lt;br /&gt;
&lt;br /&gt;
* [Raf08a] &#039;&#039;PML and strong normalization&#039;&#039; conference at the Types workshop, April 2008, Turino, Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf07b] &#039;&#039;PML: a new proof assistant&#039;&#039; conference at the Types workshop, may 2007, Cividale del Friuli (Udine), Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf06a] &#039;&#039;Realizability of the axiom of choice in HOL (An analysis of Krivines&#039;s work)&#039;&#039; with Frédéric Ruyer in Fundamenta Informaticae (2006)&lt;br /&gt;
&lt;br /&gt;
* [Raf05a] &#039;&#039;PhoX&#039;&#039; with Paul Rozière in The seventeen provers of the World, Freek Wiedijk (editor) LNAI 3600 pages 67-71&lt;br /&gt;
&lt;br /&gt;
* [Raf03b] &#039;&#039;System ST&#039;&#039; Schedae Informatica, proceedings of the Chambery-Krawow-Lyon Workshop, Vol. 12, pages 97-112 (June 2003)&lt;br /&gt;
&lt;br /&gt;
* [Raf02c] &#039;&#039;Getting results from programs extracted from classical proofs&#039;&#039;, TCS 2004, volume 323, pages 49-70&lt;br /&gt;
&lt;br /&gt;
* [Raf02b] &#039;&#039;System ST, beta-reduction and completeness&#039;&#039;, presented at LICS 2003, publication IEEE, pages 21-32&lt;br /&gt;
&lt;br /&gt;
* [Raf02a] &#039;&#039;Computer Assisted Teaching in Mathematics&#039;&#039;, with René David, to appear in the proceedings of the Workshop on 35 years of Automath (April 2002, Edingurgh)&lt;br /&gt;
&lt;br /&gt;
* [Raf01d] &#039;&#039;System ST, towards a Type System for Extraction and Proof of Programs&#039;&#039;, Archive for Pure and Applied Logic, 2003, volume 122, pages 107-130&lt;br /&gt;
&lt;br /&gt;
* [Raf01c] &#039;&#039;Apprentissage du raisonnement assité par ordinateur&#039;&#039;, avec René David, Quadrature numéro 45, printemps 2002, pages 25-36). Version courte parue dans la gazette de la SMF, avril 2002, numéro 92, pages 48-56&lt;br /&gt;
&lt;br /&gt;
==== Frederic Blanqui (INRIA, Rocquencourt) ====&lt;br /&gt;
&lt;br /&gt;
Age 38, permanent full-time researcher at [http://www.inria.fr INRIA].&lt;br /&gt;
&lt;br /&gt;
Frederic Blanqui is expert in the following areas:&lt;br /&gt;
* type theory,&lt;br /&gt;
* rewriting theory,&lt;br /&gt;
* termination,&lt;br /&gt;
* functional programming,&lt;br /&gt;
* proof assistants,&lt;br /&gt;
* and formal certification of program properties.&lt;br /&gt;
&lt;br /&gt;
Since September 2008, he is INRIA researcher at [http://liama.ia.ac.cn LIAMA], the Sino-French Laboratory in Computer Science, Automation and Applied Mathematics.&lt;br /&gt;
&lt;br /&gt;
Between 2003 and 2008, he was INRIA researcher at [http://www.loria.fr LORIA], Nancy, in the Protheo research team led by Pr Claude Kirchner, focusing on the use of rewriting techniques for programming, as well as specifying and proving program properties.&lt;br /&gt;
&lt;br /&gt;
Since 2004, he is leading the [http://color.inria.fr CoLoR] project which aims at providing tools for automatically certifying the termination of programs. Since 2007, CoLoR is the best certification back-end in the international [http://termination-portal.org/wiki/Termination_Competition competition on certified termination provers].&lt;br /&gt;
&lt;br /&gt;
In 2007 and 2008, he led the INRIA [http://quotient.loria.fr/ Quotient] project which aims at extending the [http://caml.inria.fr OCaml] programming language with types whose values automatically satisfy equational invariants using the [http://moca.inria.fr Moca] tool.&lt;br /&gt;
&lt;br /&gt;
He supervised 2 master thesis and 3 PhD students on the extension of type theory with decision procedures, the termination of typed higher-order rule-based programs, and the certification of termination proofs.&lt;br /&gt;
&lt;br /&gt;
He did his PhD with Pr Jean-Pierre Jouannaud at University Paris Sud between October 1998 and September 2001 on the combination of type theory and rewriting theory.&lt;br /&gt;
&lt;br /&gt;
Between October 2001 and August 2002, he worked on the certification of cryptographic protocols with Pr Larry Paulson at Cambridge, UK.&lt;br /&gt;
&lt;br /&gt;
Between September 2002 and September 2003, he worked at Ecole Polytechnique in the [http://coq.inria.fr Coq] development team on the extension of the proof assistant Coq with rewriting.&lt;br /&gt;
&lt;br /&gt;
More details on his activities and publications can be found on his [http://www-rocq.inria.fr/~blanqui/ web page] and in his [http://www-rocq.inria.fr/~blanqui/divers/cv.pdf CV].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
International journals with reading committee: 7&lt;br /&gt;
&lt;br /&gt;
International conferences with reading committee: 15&lt;br /&gt;
&lt;br /&gt;
Other publications (thesis, workshops, invited papers, reports, etc.): 15&lt;br /&gt;
&lt;br /&gt;
Prizes: 2001 [http://www.specif.org/ SPECIF] Award for his PhD thesis by the French national society of teachers and researchers in computer science; and 2001 Kleene Award for the best young researcher paper at the IEEE Symposium on Logic in Computer Science ([http://www2.informatik.hu-berlin.de/lics/ LICS]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Five most significant publications in the last 5 years:&lt;br /&gt;
&lt;br /&gt;
* [Bla11] F. Blanqui and A. Koprowski. &#039;&#039;CoLoR: a Coq library on well-founded rewrite relations and its application to the automated verification of termination certificates&#039;&#039;. To appear in Mathematical Structures in Computer Science.&lt;br /&gt;
&lt;br /&gt;
* [BRK10] F. Blanqui, C. Riba and C. Kirchner. &#039;&#039;On the confluence of lambda-calculus with conditional rewriting&#039;&#039;. Theoretical Computer Science 411(37), p. 3301-3327.&lt;br /&gt;
&lt;br /&gt;
* [BR09] F. Blanqui and C. Roux. &#039;&#039;On the relation between sized-types based termination and semantic labelling&#039;&#039;. CSL&#039;09. LNCS 5771.&lt;br /&gt;
&lt;br /&gt;
* [BJS08] F. Blanqui, J.-P. Jouannaud and P.-Y. Strub. &#039;&#039;From formal proofs to mathematical proofs: a safe, incremental way for building in first-order decision procedures&#039;&#039;. TCS&#039;08. IFIP 273.&lt;br /&gt;
&lt;br /&gt;
* [BHW07] F. Blanqui, Thérèse Hardin and Pierre Weis. &#039;&#039;On the Implementation of Construction Functions for Non-free Concrete Data Types&#039;&#039;. ESOP 2007: 95-109.&lt;br /&gt;
&lt;br /&gt;
==== Emmanuel Chailloux (LIP6, Paris) ====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Age 51,  full professor at the University &lt;br /&gt;
Pierre et Marie Curie ([http://www.upmc.fr UPMC - Paris 6]) in Paris France, &lt;br /&gt;
and since October 2006  researcher at the &lt;br /&gt;
[http://www.lip6.fr LIP6] computer science laboratory (UMR 7606), &lt;br /&gt;
in the &amp;quot;Algorithms, Programs and Resolution&amp;quot; team ([http://www-apr.lip6.fr APR]).&lt;br /&gt;
&lt;br /&gt;
His research work is related to design and implementation of programming languages : &lt;br /&gt;
* semantics, &lt;br /&gt;
* types systems, &lt;br /&gt;
* runtime implementation, &lt;br /&gt;
* multicores. &lt;br /&gt;
Most of the recent publications relate to safety-critical software development.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Recent publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[VWC-2011] Vaugon B., Wang P., Chailloux E. &#039;&#039; Les microcontrôleurs&lt;br /&gt;
PIC programmés en Objective Caml&#039;&#039;. Journées des Langages Applicatifs&lt;br /&gt;
(JFLA&#039;2011), janvier 2011.&lt;br /&gt;
&lt;br /&gt;
[WJC-2010] Wang P., Jonquet A., Chailloux E. &#039;&#039;Non-Intrusive&lt;br /&gt;
Structural Coverage for Objective Caml&#039;&#039;.  5th Workshop on Bytecode&lt;br /&gt;
Semantics, Verification, Analysis and Transformation (Bytecode), 2010.&lt;br /&gt;
&lt;br /&gt;
[PAMCCWMC-2009] Pagano B., Andrieu O., Moniot T., Canou B., Chailloux&lt;br /&gt;
E., Wang P., Manoury P., Colaço J.-L. &#039;&#039;Experience Report: Using&lt;br /&gt;
Objective Caml to develop safety-critical embedded tool in a&lt;br /&gt;
certificaiton framework&#039;&#039;.  International Conference of Functional&lt;br /&gt;
Programming (ICFP&#039;09), 2009.&lt;br /&gt;
&lt;br /&gt;
[CBC-2008] Canou B., Balat V., Chailloux E. &#039;&#039;O&#039;Browser : Objective&lt;br /&gt;
Caml on browsers&#039;&#039;. The 2008 ACM SIGPLAN Workshop on ML, 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;HIRONDML: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 2008, 55--69.&lt;br /&gt;
&lt;br /&gt;
[PACCCMW-2008] Pagano B., Andrieu O., Canou B., Chailloux E., Colaço J.-L., Moniot T., Wang P. &lt;br /&gt;
&#039;&#039;Certified development tools implementation in objective caml.&#039;&#039;  &lt;br /&gt;
International Symposium on Practical Aspects of Declarative Languages (PADL 08), 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;Hirondml: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 (2008) 55-69&lt;br /&gt;
&lt;br /&gt;
[HMC-2007] Henry G., Mauny M., Chailloux E. &#039;&#039;Typer la désérialisation&lt;br /&gt;
sans sérialiser les types&#039;&#039;. Technique et Science Informatiques 26, 9&lt;br /&gt;
(2007) 1067-1090.&lt;br /&gt;
&lt;br /&gt;
[CM-2006] Chailloux E., Mauny M. &#039;&#039;Programmation fonctionnelle&#039;&#039;.&lt;br /&gt;
Encyclopédie de l&#039;informatique et des systèmes d&#039;information (2006)&lt;br /&gt;
1016--1027.&lt;br /&gt;
&lt;br /&gt;
==== Tom Hirschowitz (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
34 ans, CR CNRS (informatique) , LAMA&lt;br /&gt;
&lt;br /&gt;
* 2007         CR CNRS au LAMA (UMR 5127) à Chambéry&lt;br /&gt;
* 2004-2007    CR CNRS au LIP (UMR5668) à Lyon&lt;br /&gt;
* 2003-2004    ATER, équipe Plume, LIP, ENS Lyon&lt;br /&gt;
* 2000-2003    Doctorat (dir.: X. Leroy, INRIA Rocquencourt, projet Cristal)&lt;br /&gt;
* 1999-2000    DEA à Paris 7&lt;br /&gt;
* 1996-2000    Ecole Nationale des Ponts et Chaussées&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;10 publications dans des revues et conférences internationales&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;publications choisies&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
# T. Hirschowitz, X. Leroy, and J. B. Wells. Compilation of extended recursion in call-by-value functional languages, PPDP 2003. Version journal dans Higher-Order and Symbolic Computation 22-1. 2009.&lt;br /&gt;
# R. Garner, T. Hirschowitz, and A. Pardon. Variable Binding, Symmetric Monoidal Closed Theories and Bigraphs. CONCUR&#039;09. 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. Contraction-free Proofs and Finitary Games for Linear Logic. MFPS, 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. A Theory for Game Theories. FSTTCS, 2007.&lt;br /&gt;
# T. Hirschowitz, X. Leroy. Mixin Modules in a Call-by-Value Setting, ESOP, 2002, journal version in ACM Transactions on Programming Languages and Systems, 2005.&lt;br /&gt;
&lt;br /&gt;
==== Pierre Hyvernat (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
Age 30, &amp;quot;maître de conférences&amp;quot; at the Université de Savoie (in Chambéry) since September 2006, member of the [http://www.lama.univ-savoie.fr LAMA].&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2005, under the supervision of Thierry Coquand (Chalmers, Göteborg, Sweden) and Thomas Ehrhard (at the time, IML, Luminy, Marseille, France)&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include&lt;br /&gt;
* denotational semantics,&lt;br /&gt;
* type theory and constructive mathematics.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Hyv10b] &#039;&#039;The Size-Change Termination Principle for Constructor Based Languages&#039;&#039; (hal-00547440, submitted)&lt;br /&gt;
&lt;br /&gt;
* [HHy06] with P. Hancock: &#039;&#039;Programming Interfaces and Basic Topology&#039;&#039;. &amp;quot;Annals of Pure and Applied Logic&amp;quot;, volume 137, January 2006,&lt;br /&gt;
&lt;br /&gt;
* [Hyv05] &#039;&#039;Synchronous Games, Simulations and lambda-calculus&#039;&#039;, proceedings of the &amp;quot;GaLoP&amp;quot; workshop, ETAPS 2005. (journal version submitted to Annals of Pure and Applied Logic),&lt;br /&gt;
&lt;br /&gt;
* [Hyv04] &#039;&#039;Predicate Transformers and Linear Logic: yet another Denotational Model&#039;&#039;, Lecture Notes in Computer Science, vol. 3210, September 2004.&lt;br /&gt;
&lt;br /&gt;
==== Alexandre Miquel (PPS, Paris 7) ====&lt;br /&gt;
&lt;br /&gt;
Age 37, &amp;quot;maître de conférences&amp;quot; at the Université Paris-Diderot (Paris 7) since September 2003, member of [http://www.pps.jussieu.fr/ PPS]. Currently CNRS research associate (&amp;quot;délégation&amp;quot;) in the Plume team at the LIP (ENS Lyon) since September 2008.&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2001, under the supervision of Hugo Herbelin (INRIA/LIX) in the Coq team (now TypiCal).&lt;br /&gt;
&lt;br /&gt;
From October 2001 to August 2002 he was postdoc in the Chalmers Institute of Technology (Göetborg, Sweden) under the supervision of Thierry Coquand, and from September 2002 to August 2003 he was &amp;quot;ATER&amp;quot; at the LRI (Orsay).&lt;br /&gt;
&lt;br /&gt;
He is a specialist of the models of type theory (especially the calculus of constructions) and of the correspondence between set theory and type theory. His research interests also include:&lt;br /&gt;
* logic, proof-theory, rewriting,&lt;br /&gt;
* denotational semantics (set- and domain-theoretic),&lt;br /&gt;
* realizability in classical logic.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
His most significant publications are:&lt;br /&gt;
&lt;br /&gt;
* [Miq07] &#039;&#039;Classical program extraction in the calculus of constructions&#039;&#039; (CSL&#039;07),&lt;br /&gt;
&lt;br /&gt;
* [Miq06] with A. Arbiser and A. Ríos. &#039;&#039;A lambda-calculus with constructors&#039;&#039; (RTA&#039;06),&lt;br /&gt;
&lt;br /&gt;
* [Miq04] &#039;&#039;Lambda-Z: Zermelo&#039;s Set Theory as a PTS with 4 Sorts&#039;&#039; (TYPES&#039;04),&lt;br /&gt;
&lt;br /&gt;
* [Miq03] &#039;&#039;A Strongly Normalising Curry-Howard Correspondence for IZF Set Theory&#039;&#039; (CSL&#039;03),&lt;br /&gt;
&lt;br /&gt;
* [Miq00] &#039;&#039;A Model for Impredicative Type Systems with Universes, Intersection Types and Subtyping&#039;&#039; (LICS&#039;00).&lt;br /&gt;
&lt;br /&gt;
==== Christophe Mouilleron (LIP, ENS de Lyon) ====&lt;br /&gt;
&lt;br /&gt;
Age 26, PhD student in the Arenaire team at the LIP (ENS de Lyon) since September 2008. He works under the supervision of Claude-Pierre Jeannerod (INRIA/LIP) and Gilles Villard (CNRS/LIP).&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include :&lt;br /&gt;
* computer arithmetic,&lt;br /&gt;
* code generation,&lt;br /&gt;
* formal proof of numerical properties in programs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [MouRev10] C. Mouilleron and G. Revy. &#039;&#039;Automatic Generation of Fast and Certified Code for Polynomial Evaluation.&#039;&#039; (submitted, available as ensl-00531721)&lt;br /&gt;
&lt;br /&gt;
* [JeaMou10] C.-P. Jeannerod and C. Mouilleron. &#039;&#039;Computing Specified Generators of Structured Matrix Inverses.&#039;&#039; (ISSAC&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [BJJK+10] C. Bertin, C.-P. Jeannerod, J. Jourdan-Lu, H. Knochel, C. Monat, C. Mouilleron, J.-M. Muller, and G. Revy. &#039;&#039;Techniques and tools for implementing IEEE 754 floating-point arithmetic on VLIW integer processors.&#039;&#039; (PASCO&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [LTdD+10] V. Lefèvre, P. Théveny, F. de Dinechin, C.-P. Jeannerod, C. Mouilleron, D. Pfannholzer, and N. Revol. &#039;&#039;LEMA : Towards a Language for Reliable Arithmetic.&#039;&#039; (PLMMS&#039;10)&lt;br /&gt;
&lt;br /&gt;
===Relevant publications by non participants to the project ===&lt;br /&gt;
&lt;br /&gt;
Here are some publication or resources of interest for the project:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Laguage design and theory:&#039;&#039;&#039;&lt;br /&gt;
* [SOW97] Martin Sulzmann, Martin Odersky, Martin Wehr, &#039;&#039;Type inference with constrained types&#039;&#039;, TAPOS, 1997.&lt;br /&gt;
* [HW04] Christian Haack and J. B. Wells, &#039;&#039;Type error slicing in implicitly typed higher-order languages&#039;&#039;, Sci. Comput. Programming, 50:189-224, 2004.&lt;br /&gt;
* [Ruy06] Frédéric Ruyer, &#039;&#039;Preuves, types et sous-type&#039;&#039;, phd 2006 directed by C. Raffalli.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Termination:&#039;&#039;&#039;&lt;br /&gt;
* [LJ01] Lee, Jones, et al. &#039;&#039;The size-change principle for program termination&#039;&#039; - ACM SIGPLAN Notices - 2001&lt;br /&gt;
* [Abel04] Andreas Abel, &#039;&#039;Termination Checking with Types&#039;&#039; ,Special Issue: Fixed Points in Computer Science (FICS&#039;03 and RAIR&#039;04)&lt;br /&gt;
* [Bar04]   G. Barthe, M. J. Frade  and E. Giménez, L. Pinto and T. Uustalu, &#039;&#039;Type-Based Termination of Recursive Definitions&#039;&#039;, 2004, Mathematical Structures in Computer Science.&lt;br /&gt;
* [Gie06] J. Giesl, S. Swiderski, P. Schneider-Kamp, and R. Thiemann &#039;&#039;Automated Termination Analysis for Haskell: From Term Rewriting to Programming Languages&#039;&#039;, Proceedings of the 17th International Conference on Rewriting Techniques and Applications (RTA-06), Lecture Notes in Computer Science 4098.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;the Clean language:&#039;&#039;&#039;&lt;br /&gt;
* [AGR92] Peter Achten, John van Groningen and Rinus Plasmeijer (1992). &#039;&#039;High-level specification of I/O in functional languages&#039;&#039;, Proc. of the Glasgow workshop on Functional programming, ed. J. Launchbury and P. Sansom, Ayr, Scotland, Springer-Verlag, Workshops in Computing, pp. 1-17.&lt;br /&gt;
* [AcP95] Peter Achten and Rinus Plasmeijer (1995). &#039;&#039;The Ins and Outs of CONCURRENT CLEAN I/O&#039;&#039;, Journal of Functional Programming, 5, 1, pp. 81-110.&lt;br /&gt;
* [AcP97] Peter Achten and Rinus Plasmeijer (1997). &#039;&#039;Interactive Functional Objects in CLEAN&#039;&#039;, Proc. of the 1997 Workshop on the Implementation of Functional Languages (IFL&#039;97), ed. K. Hammond Davie, T., and Clack, C., St.Andrews, Scotland,&lt;br /&gt;
* [VPA07] Edsko de Vries, Rinus Plasmeijer, and David M. Abrahamson, &#039;&#039;Uniqueness Typing Simplified, by Edsko de Vries&#039;&#039;,&lt;br /&gt;
* [http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf the language report] by Rinus Plasmeijer and Marko van Eekelen,&lt;br /&gt;
* [http://clean.cs.ru.nl/ the language homepage].&lt;br /&gt;
&lt;br /&gt;
===Involvement of project participants to other grants, contracts, etc …===&lt;br /&gt;
&lt;br /&gt;
* Emmanuel Chailloux is member of the ANR PWD (&amp;quot;Programmation du Web Diffus&amp;quot;), whose leader is Manuel Serrano (Inria), and the FUI [http://opengpu.net/ OpenGPU project].  &lt;br /&gt;
* Tom Hishowitz is involved in the ANR PiCoq the ANR proposals RÉCRÉ and CATHRE.&lt;br /&gt;
* Pierre Hyvernat is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Alexandre Miquel is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Christophe Raffalli is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
&lt;br /&gt;
Remark: the interaction with PML and RÉCRÉ is natural because the proof technics used for ensuring some of the properties of the language PML is realizability which is one of the théma of the ANR proposal RÉCRÉ.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5085</id>
		<title>ANR PML</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5085"/>
		<updated>2011-01-13T11:16:08Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Tom Hirshowitz (LAMA, Chambéry) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;URL of PML project: &amp;lt;tt&amp;gt;http://lama.univ-savoie.fr/tracpml&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Context and positioning of the proposal==&lt;br /&gt;
&lt;br /&gt;
Ever since FORTRAN appeared fifty years ago, programming languages have been evolving rapidly. These languages now include more and more sophisticated concepts like &amp;quot;objects&amp;quot;, &amp;quot;type inference&amp;quot;, &amp;quot;modules&amp;quot;... However, this richness is also what makes it more and more complex to train programmers and makes it difficult for them to keep up with the innovations and changes in programming languages.&lt;br /&gt;
&lt;br /&gt;
Another orthogonal phenomenon is the emergence of formal methods used in conjunction with various programming languages to test, check or prove software. This introduces another layer to languages in order to write specifications, and sometimes yet another one for proofs. Learning a programming language together with the associated specification/proof languages can take an important effort.&lt;br /&gt;
&lt;br /&gt;
Projects such as [http://www.cs.utexas.edu/users/moore/acl2/ ACL2], the successor of  [http://www.cs.utexas.edu/users/boyer/ftp/nqthm nqthm, the Boyer-Moore theorem prover] uses a rather simple language (namely LISP) both as a programming language and specification language, allowing to keep a unity in the system. Unfortunately, LISP is somewhat limited both as a programming language (no good treatment of sum type, no module system) and a specification language (very limited quantification). Moreover, LISP has no compile-time type-checking, which has proved very useful to detect bugs and automatically assert properties.&lt;br /&gt;
&lt;br /&gt;
The aim of this project is to build a very powerful language (with no loss of expressive power compared to state of the art languages) based on a very small number of simple features. We think this will be possible thanks to recent progress both in the semantics of programming languages and the apparition of new algorithms for type inference based on constraints-solving. In fact, we propose in [RAF10b] an innovative concept derived from the later to enable this: constraints-checking.&lt;br /&gt;
&lt;br /&gt;
Moreover, the language will be used not only as a programming language and a specification language (like in ACL2), but also as the proof language. This is natural for an ML-like language because pattern-matching is a natural and powerful way to make a proof by case analysis. This also means that our tool will follow the &#039;&#039;KISS&#039;&#039; philosophy: relatively few (unified) features, yet powerful.&lt;br /&gt;
&lt;br /&gt;
The idea of a new language arose from the discovery of a new typing algorithm [RAF10b] whose implementation gave birth to a first implementation of PML (Proved ML) by Christophe Raffalli. This implementation is already available from [http://www.lama.univ-savoie.fr/~pml the web page of the language]. However, turning PML into a real tool requires a lot of research and implementation work and this is why we request the help of the ANR. Some of the goals are highlighted in the next sections.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML approach to proofs of specification is unique&#039;&#039;&#039; PML has no dedicated proof language, but the user can still write proofs! Existing programming languages supporting specifications use two alternatives: automated proofs (ACL2, Why) or proof obligations that the user can prove using specific language (Coq extraction, Focalize, Why). Several systems provide both, the manual proofs being used only when automation fails. PML is very different in spirit: it introduces a new instruction, written with a &amp;quot;scissors symbol&amp;quot; &amp;lt;tt&amp;gt;&#039;&#039;&#039;8&amp;lt;&#039;&#039;&#039;&amp;lt;/tt&amp;gt; to express that the corresponding position in the program is &#039;&#039;dead&#039;&#039;, meaning that it can not be reached during evaluation. This condition is checked by a terminating variant of the Knuth-Bendix completion algorithm. This is rather simple and therefore easier to trust than modern decision procedures. However, it only solves trivial cases: to write complex proofs, the user just uses the same syntax as for programs to do case analysis or induction (&#039;&#039;ie.&#039;&#039; recursive definitions). This means that the user does not need learn a specific proof language and hopefully implies that PML is easier to learn and probably more adapted to industry that previous solutions.&lt;br /&gt;
&lt;br /&gt;
The logic of PML is just the equational theory of its programming language; and we use variants of Knuth-Bendix completion as a proof-checker. The first experiments with the current implementation are promising. However, Knuth-Bendix procedure in the context of ML is a complex and new research problem. A lot more work is needed, for instance to handle proofs in arithmetic which occur quite often. Here is an example of a proof in arithmetic, checked in the current version of PML. This is not completely satisfactory (hard to write), but shows the use of the language for both proofs and programs and the use of recursive functions for inductive proofs:&lt;br /&gt;
&lt;br /&gt;
  val rec mul_associative x y z |- (x * y) * z == x * (y * z)&lt;br /&gt;
    proof match x with&lt;br /&gt;
      Z[] -&amp;gt; 8&amp;lt; (* trivial case handled automatically by Knuth-Bendix *)&lt;br /&gt;
    | S[x&#039;] -&amp;gt;&lt;br /&gt;
      let _ = mul_associative x&#039; y z in (* There is a syntactic sugar for that... *)&lt;br /&gt;
        (* this adds the fact that (x&#039;*y) * z == x&#039; * (y*z) to the environment *)&lt;br /&gt;
 &lt;br /&gt;
      let _ = mul_right_distributive y (x&#039; * y) z in&lt;br /&gt;
        (* this adds the fact that (y + x&#039;*y) * z == y*z + (x&#039;*y)*z *)&lt;br /&gt;
 &lt;br /&gt;
        (* the environment now contains enough information for Knuth Bendix to handle the rest:&lt;br /&gt;
         *    - x*(y*z)  ==  y*z + x&#039;*(y*z)  : by definition&lt;br /&gt;
         *    - x*y == y + x&#039;*y : by definition&lt;br /&gt;
         *      and so (x*y)*z == (y + x&#039;*z)*z&lt;br /&gt;
         *    - (x&#039;*y) * z == x&#039; * (y*z)  :  by the recursive call to mul_associative&lt;br /&gt;
         *    - (y + x&#039;*y) * z == y*z + (x&#039;*y)*z : by the call to mul_right_distributive  *)&lt;br /&gt;
      8&amp;lt;&lt;br /&gt;
&lt;br /&gt;
Moreover, this style of proof is declarative and relatively readable (like Mizar proofs) while concise at the same time. This is very important when you want to maintain large developments.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;PML is different from the other modern programming languages&#039;&#039;&#039; because its design focuses on a few powerful concepts. One consequence is that it is more difficult for a compiler to produce efficient code. In particular, since PML unifies several notions of products (modules, tuples and records), there is no simple way to choose the internal representation of a product, especially with implicit subtyping. Writing a good compiler for PML will thus require more complex and original optimization schemes (probably driven by typing) than languages like OCaml or Haskell. A Polish student (Wojciech Matyjewicz) is just starting a PhD on this very topic.&lt;br /&gt;
&lt;br /&gt;
Here is a simple example, accepted by the current version of PML, demonstrating product type, sum type and subtyping. We define ternary trees as an extension of binary trees with an implicit subtyping&lt;br /&gt;
relation (all functions accepting binary_trees will accept ternary trees, by ignoring the &amp;lt;tt&amp;gt;middle_son&amp;lt;/tt&amp;gt;):&lt;br /&gt;
&lt;br /&gt;
 type rec binary_tree (A) =&lt;br /&gt;
   [ Nil[] | Node[A with left_son : binary_tree(A); right_son : binary_tree(A)] ; ]&lt;br /&gt;
 type rec ternary_tree(A) =&lt;br /&gt;
   binary_tree({ A with middle_son : ternary_tree(A) ;})&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML requires a termination criterion&#039;&#039;&#039; because a proof by induction will just be a normal recursive program. Such a program has to be well-founded in order to correspond to a valid proof. A subset of Haskell can now use the Aprove tool to establish termination for simple programs. However, we want the test to be fully integrated with the language, and be compatible with very modular programs. At the moment, these goals seem difficult to achieve with Aprove or other external termination checkers. A first termination criterion based on Lee, Jones &amp;amp; Ben-Amram&#039;s &amp;quot;size-change termination principle&amp;quot; was implemented by Pierre Hyvernat [Hyv10b]. While this test is quite powerful, it is necessarily incomplete, and quite some work is required to make termination proofs of complex programs tractable.&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical description==&lt;br /&gt;
&lt;br /&gt;
===Background, state of the art===&lt;br /&gt;
&lt;br /&gt;
====Programming language====&lt;br /&gt;
&lt;br /&gt;
The ML programming language, created by Robin Milner &amp;lt;em&amp;gt;et al&amp;lt;/em&amp;gt; in the 80&#039;s has two major distinctive features:&lt;br /&gt;
* Algebraic data-types and pattern matching: data types are basically all constructed using fixpoint, Cartesian product (product types) and disjoint union (sum types).&lt;br /&gt;
* Static type inference: the type of every piece of code is automatically inferred using Hindley-Milner algorithm (HM). By construction, once compiled, an ML program can not crash (no segmentation fault). More precisely, when we do not use unsafe features of the language (like interface with unsafe libraries written in C), if an ML program produces a segmentation fault, then there is a bug in the type-checker or the compiler.&lt;br /&gt;
&lt;br /&gt;
Recent progress in type inference algorithm uses constraint solving. This means that the type system can be described in first-order predicate logic in such a way that a type inference problem is a formula written in a decidable fragment of first-order predicate logic (often the purely existential fragment). Hence, any constraint solver can be turned into a type-checker for ML. These approach is known as HM(X) (see [SOW97]).&lt;br /&gt;
&lt;br /&gt;
There are two problems with this approach:&lt;br /&gt;
* The complexity of constraint solving can be too high for practical use, especially when using a general purpose constraint solver. To our knowledge, there are currently no mainstream implementation of ML based on HM(X).&lt;br /&gt;
* HM(X) does not completely solve the problem of subtyping. The language to express the types constructed by the constraint solver is the same as the language of types used by programmers. With constraints &amp;lt;math&amp;gt;\alpha \subseteq \beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\alpha \subseteq \gamma&amp;lt;/math&amp;gt; for three types &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\gamma&amp;lt;/math&amp;gt;, the most natural solution is &amp;lt;math&amp;gt;\alpha = \beta \cap \gamma&amp;lt;/math&amp;gt;. This implies that intersection needs to be part of the language for types. This means that constraints such as &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \delta&amp;lt;/math&amp;gt; may also appear and they are problematic to deal with. Similar reasoning shows that constraints of the form &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \beta&#039; \cup \gamma&#039;&amp;lt;/math&amp;gt; may appear, increasing the complexity of constraint solving by an exponential factor.&lt;br /&gt;
&lt;br /&gt;
PML&#039;s approach is to replace type-inference by &#039;&#039;constraint &amp;lt;u&amp;gt;checking&amp;lt;/u&amp;gt;&#039;&#039; rather than constraint solving: we only check that the constraints are satisfiable in some model. Type-checking in the current implementation of PML can be seen as a black box ensuring that nothing can go wrong during execution. Moreover, since we do not need to write solutions for the constraints, the language for types can be relatively simple. In fact, the types written by the programmer aren&#039;t even the actual type constraints that are checked: they are syntactic sugar for the partial identity on the intended type (giving for free nice feature like higher-order parametric types, that is types with parameters which may be themselves types with parameters). In other words, the expression &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; is a synonym for &amp;lt;tt&amp;gt;(id_nat x)&amp;lt;/tt&amp;gt; where&lt;br /&gt;
  val rec id_nat x = match x with&lt;br /&gt;
      Z[] -&amp;gt; Z[]&lt;br /&gt;
    | S[x&#039;] -&amp;gt; S[id_nat x&#039;]&lt;br /&gt;
is defined internally by PML. The constraints generated by &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; mean exactly that &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is of type &amp;lt;tt&amp;gt;nat&amp;lt;/tt&amp;gt;...&lt;br /&gt;
&lt;br /&gt;
With this approach, we loose type-inference and the ability to display types in error messages. Nevertheless, PML error reporting is quite helpful because, in case of problems, it displays three positions in the code and an error message like this &amp;lt;tt&amp;gt;error at position 1, label &amp;quot;id&amp;quot; projected at position 2 do not appear in the value constructed at position 3&amp;lt;/tt&amp;gt;. This kind of error message is in fact of bounded length and often more useful than OCaml or SML messages. We can understand this as showing three points in the &#039;&#039;slice&#039;&#039; of the error, as introduced by Joe Wells in [HW04].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Proof assistant====&lt;br /&gt;
&lt;br /&gt;
Proof assistants have evolved rapidly since Automath in the 70th. Two main trends coexist: automated proof assistants such as ACL2, PVS and &#039;&#039;safe&#039;&#039; ones such as Coq, Isabelle, PhoX, Lego, HOL, Matita, &amp;lt;em&amp;gt;etc.&amp;lt;/em&amp;gt; The former incorporate very sophisticated automated deduction strategies, with no &#039;&#039;certificate&#039;&#039; for the validity of the proof, while the later require all proofs to be done in a specific framework (like natural deduction or type theory) allowing for a simple check of the proof. The gap between the two approaches tend to be reduced by the emergence of complex tactics (for Coq or Isabelle mainly) which build proofs for the user. For instance Zenon is an advanced automated first-order theorem prover that outputs a Coq proof.&lt;br /&gt;
&lt;br /&gt;
The common defect of all these proof assistants is that a proof can not be written nor understood without running the proof assistant. Some proof assistants such as Mizar or Alf do not follow exactly the above scheme: Mizar has a declarative style for proof which is (in theory) readable by a human and checked by a limited checker (This proof style has been adapted to Coq and Isabelle). Unfortunately, there is no formal description of the Mizar proof checker. Alf on the other hand is based on proof theory and requires the user to basically write the complete proof tree just leaving out a few details. The logic is very well formalized and simple, but writing proof is tedious and not similar to the usual practice of informal mathematics.&lt;br /&gt;
&lt;br /&gt;
This picture of the world of proof assistants shows that some fundamental work is needed. In the current version of PML, the logic is just an equational theory of the underlying programming language. This is easily described formally. The proof engine is, like in Mizar, a limited automated checker inspired by the Knuth-Bendix completion algorithm (KB). The completion algorithm used in PML had to be adapted to the higher-order constructs of ML-like languages and restricted to ensure termination and an acceptable complexity. The current limitation is probably too strong: it is limited to closed terms and cannot use universal theorems automatically (as in the first example of section 1, where one has to give explicitly the argument to use distributivity).&lt;br /&gt;
&lt;br /&gt;
Nevertheless, preliminary examples in the current version shows that the approach is worth trying: proofs are concise and readable once you know the language. A very encouraging point is that all examples where written without interface. This really means that proofs are readable without the help of a computer.&lt;br /&gt;
&lt;br /&gt;
===Rationale highlighting the originality and novelty of the proposal===&lt;br /&gt;
&lt;br /&gt;
The final objective of our project would be a full PML compiler, bootstrapped and completely proved with itself (full bootstrap). This does not exist for any language and is far too ambitious for a four years project.  More realistically, we plan to produce a compiler for PML, written in PML, but not proved in PML yet.&lt;br /&gt;
&lt;br /&gt;
We also want to develop proof-checking in such a way as to allow very elegant proofs, supporting the feasibility of a full bootstrap by various examples, some of them being near to industrial application, some others being algorithms coming from implementation of programming languages.&lt;br /&gt;
&lt;br /&gt;
We have focused the existing development on the quality of the language both for proofs and programs. By quality, we mean easy to understand and write (and therefore, easy to learn). We think that using the programming language as a proof language could make formal methods more attractive to the industry without the defect of systems like PVS and ACL2 where the automated tactics replace the need for a proof language, but are sometimes hard to control and use. For instance, finding the right &#039;&#039;lemmas&#039;&#039; to make a proof possible in ACL2 is quite difficult.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other proof systems devoted to programming.&#039;&#039;&#039; Many other proof systems have been used or specifically developed&lt;br /&gt;
to allow the production of certified code: extraction in Coq, Why with its automated prover Who from the Proval project, Focalize, PVS, ATS, ... None of these system uses the programming language as a proof language. They all have a dedicated language for proofs and even if some of them like Focalize or Coq extraction using a Mizar style mode for proof, have readable proofs, learning the proof language is never trivial. Other systems like PVS, ATS, Why using Who rely on automated deduction. In those cases, the behavior of the automated prover is always hard to predict.&lt;br /&gt;
&lt;br /&gt;
Another selling point is that the logic and programming language are fully integrated. This is not a two level systems like most systems (but not all, ACL2 for instance is fully integrated). In PML, the statements of theorems and their proofs are expressions at the same level than programs. This means that a program can contain specifications that contains themselves program definitions in their statement or proof and so on. This is generally not possible (even in ACL2) and makes it possible to write modules with their specifications.&lt;br /&gt;
&lt;br /&gt;
One of the key idea for this project is that any ML-like programming language has all the features needed for a proof language: case analysis via pattern matching and exception handling, induction, calling previously defined program/theorems. This means that it is natural to explore this direction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other programming languages&#039;&#039;&#039;. Another key idea in PML is to develop the language and its proof-checker together. This has a great impact on the design of PML. Let&#039;s illustrate this with a concrete example: exception handling. In ML, there is a construct&lt;br /&gt;
  try P with e -&amp;gt; R&lt;br /&gt;
but, this is not sufficient to do case analysis on the fact that a program &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises or not an exception. In particular, &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; can be the proof just in case &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises an exception. However there is no place holder for the normal case (without exception). This is why we had to introduce a&lt;br /&gt;
  let try x = P in Q with e -&amp;gt; R&lt;br /&gt;
where &amp;lt;tt&amp;gt;Q&amp;lt;/tt&amp;gt; is evaluated only when &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; reduces to a value.&lt;br /&gt;
&lt;br /&gt;
A great number of decisions on the language design comes from the interaction between the development of the programming language and its proof-checker. Another key feature of PML, which makes the project original even as a programming language compared to many other projects of programming language research (GALLIUM, Haskell, Scala, ...) is the use of constraint checking. This choice arises from the fact that we want a language as small as possible, because a proof-checker is complex and therefore, we want to fully unify all sorts of Cartesian product including modules, records, tuples and variant with multiple argument. This is already achieved in the current implementation of PML and to my knowledge, no ML like language have a unique but still powerful notion of Cartesian product.&lt;br /&gt;
&lt;br /&gt;
All the systems previously mentioned allow to prove programs in limited subsets of existing languages like ML or Haskell. The prover has to find ways to deal with those languages&#039; defects rather than improve them...&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical program, project management==&lt;br /&gt;
&lt;br /&gt;
===Specific aims of the proposal===&lt;br /&gt;
&lt;br /&gt;
As said in the previous section, the final objective would be to have a fully bootstrapped PML language: this would mean that PML is entirely written and proved in PML. This would be too ambitious at first, and we chose to focus here on the design of the language plus a proof of concept, that is compilation and proof of various examples, searching to do our best on the following points:&lt;br /&gt;
&lt;br /&gt;
* Natural way of writing programs (Task 1)&lt;br /&gt;
* Efficiency of the code generated by the compiler, despite the heavily use of subtyping (Task 3)&lt;br /&gt;
* Readable and short proofs (Task 1, Task 4)&lt;br /&gt;
* Efficiency of type-checking and compilation (Task 2 and 6)&lt;br /&gt;
* Efficiency of proof-checking (Task 4 and 6)&lt;br /&gt;
* All of the above points need testing, and we created a transverse fifth task for that.&lt;br /&gt;
&lt;br /&gt;
===Project management===&lt;br /&gt;
&lt;br /&gt;
We plan to have one 3 days workshop per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems. We already have the agreement of some people to participate in such meetings: Joe Wells, Assia Mahbouby, Andreas Abel, ...&lt;br /&gt;
We plan to have one 3 days meetings per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems.&lt;br /&gt;
&lt;br /&gt;
We will also organize two project meetings per year, just to keep track of progress, share idea and organize the above workshops and other invitations.&lt;br /&gt;
&lt;br /&gt;
We want also to organize visits of one or two members of the project to visit researchers on similar topic (typically a member of the project could visit one of the invited speaker of our workshop). Members of the project should also travel to conference on the subject like POPL, LICS, CSL, TYPES or the recently created CPP (first conference in 2011).&lt;br /&gt;
&lt;br /&gt;
===Detailed description of the work organized by tasks===&lt;br /&gt;
&lt;br /&gt;
====Task 1 - theoretical work, design of the language ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Alexandre Miquel, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.a - Correctness of the constraint checking algorithm&#039;&#039;&#039; (delivered&lt;br /&gt;
09/2012): [RAF10b] already cover the correctness without polymorphism. A draft version of &lt;br /&gt;
the correctness proof with polymorphism does exist but needs more work. The &lt;br /&gt;
main open problem here is the interaction with the termination-check. The current work &lt;br /&gt;
proves that when constraints are checked, the program can only loop via recursive definitions.&lt;br /&gt;
Then, we would like to prove that the program is terminating if recursive definitions are accepted by the &lt;br /&gt;
termination checker. However, this is non trivial.&lt;br /&gt;
&lt;br /&gt;
This being a central piece of PML, it should be also one&lt;br /&gt;
of the first tests for PML in task 5. We could also prove this part of PML in&lt;br /&gt;
Coq (in fact 2 provers proving themselves and each other correct is a much&lt;br /&gt;
stronger warranty than one prover proving itself).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.b - Consistency of proof-checking&#039;&#039;&#039; (beginning 09/2011, delivered before 09/2013 for the core of the language): This is essential for clearly defining the logic of PML and prove its consistency. This should not be too hard for the core of the language. However, this proof has to be extended to take into account all future extensions of the language and could be seen as a &#039;&#039;permanent task&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.c - Adaptation of uniqueness typing to the context of constraint checking&#039;&#039;&#039; (beginning 09/2012, delivered 01/2014): The current version of PML is a pure functional programming language, with no imperative feature. This is problematic, because input/output is necessary for real programs and affectations are required for efficiency especially when using large arrays. We plan to adapt the approach of the [http://clean.cs.ru.nl/ Clean language] [AGR92], [AcP95], [AcP97], [VPA07]. In Clean, all programs can be analyzed as purely functional programs, but the type system can check that some data are not used any more and reuse the place in memory for other data (allowing affectation). For instance, in such a context writing in a file &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; can be written as &amp;lt;tt&amp;gt;let f&#039; = write f str in ...&amp;lt;/tt&amp;gt;, but the compiler must check that &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; will not be used anymore implying the equivalence between the standard imperative semantics of writing to file and the purely functional semantics used by proofs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.d - Private, abstract and existential types.&#039;&#039;&#039; (beginning 09/2011, delivered&lt;br /&gt;
09/2012 for private type, beginning 09/2012, delivered&lt;br /&gt;
09/2013 for existential types and beginning 09/2013, delivered 09/2015 for abstract&lt;br /&gt;
types)&lt;br /&gt;
 &lt;br /&gt;
Abstract data types hide the definition of a data type and allow the user of&lt;br /&gt;
a library to be sure that his code will continue to work even if the internal&lt;br /&gt;
representation of data are changed. In the context of constraint-checking in&lt;br /&gt;
PML, adding abstract data types seems to be a challenging task. Moreover,&lt;br /&gt;
abstract data-types are a form of existential quantification over types and&lt;br /&gt;
could raise some consistency issues. We hope to find a way to incorporate&lt;br /&gt;
abstract types in PML without loosing coherence.&lt;br /&gt;
 &lt;br /&gt;
A first step would be private data types. They are a very simple yet very powerful mechanism for easily&lt;br /&gt;
ensuring invariants on all values of a data type. This mechanism is as&lt;br /&gt;
follows: the compiler simply checks that the constructors of a data type are&lt;br /&gt;
not used for constructing values. Values are constructed by using construction&lt;br /&gt;
functions, like with abstract data types. However, unlike with abstract data&lt;br /&gt;
types, constructors can still be used as patterns for defining functions by&lt;br /&gt;
pattern-matching. Hence, a library on a private data type is not closed but&lt;br /&gt;
can be extended easily. Private data types are therefore an important and very&lt;br /&gt;
useful feature for defining data structures with complex invariants and&lt;br /&gt;
proving their correctness more easily. They have been implemented in OCaml by&lt;br /&gt;
Pierre Weis and are described in Frédéric Blanqui, Thérèse Hardin and Pierre&lt;br /&gt;
Weis&#039; ESOP&#039;07 paper [BHW07].&lt;br /&gt;
&lt;br /&gt;
A second step would be existential types, which are very similar to abstract types,&lt;br /&gt;
but with no free name for the abstract type. On a logical level, they do imply an existential quantification over types&lt;br /&gt;
which has to be limited to ensure consistency. However existential types do not require the type to have a free name, which corresponds in logic to a definite description operator (similar to Hilbert&#039;s epsilon operator), and this, being connected to the axiom of choice (over types), may be really problematic for consistency. Some work related to this exists in the phd thesis of F. Ruyer, a former student of C. Raffalli [Ruy06].&lt;br /&gt;
&lt;br /&gt;
====Task 2 - termination====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Pierre Hyvernat&lt;br /&gt;
&lt;br /&gt;
Participants: Christophe Raffalli, Andreas Abel, Frederic Blanqui&lt;br /&gt;
&lt;br /&gt;
Remark: this is an essential task, running during the 4 years. There will always be some embarrassing examples that do not work, but could work... both for the core and auxiliary criterion (see below for the distinction) meaning that this research field will remain open forever.&lt;br /&gt;
&lt;br /&gt;
Even if it might be counter-intuitive at first, it is often necessary to write programs whose execution can be infinite. For example, any kind of &amp;quot;server&amp;quot;, or almost any interactive program might have infinite executions. Even in purely mathematical setting, it can be interesting to have intermediary non-terminating functions. Consider a function outputting the stream of prime numbers : even if this function is non-terminating, we might use it in a terminating manner in a proof by requesting the &#039;&#039;n&#039;&#039; first prime numbers.&lt;br /&gt;
&lt;br /&gt;
Since PML uses full recursion (keyword &amp;lt;tt&amp;gt;rec&amp;lt;/tt&amp;gt;), writing such programs is easy. On the other hand, the notion of &amp;quot;terminating&amp;quot;, or &amp;quot;well-founded&amp;quot; recursive function isn&#039;t part of the core of PML: such programs are just special cases of recursive programs. The user will have to specify which functions are in fact terminating and might have to prove it himself when PML cannot infer termination automatically.&lt;br /&gt;
&lt;br /&gt;
Proofs of specifications are just PML programs, and those cannot be allowed to run infinitely. More precisely, even if proof will never be run at all (no computational content), they are required to be well-founded. The consistency of PML relies on this. In order to relieve the user from proving that all proofs are in fact terminating, PML should offer a way to check automatically that (some) functions are terminating. Because the halting problem is undecidable, it is hopeless to do that in all generality, but this is seldom necessary: many proofs terminate for obvious reasons. PML should only work for most of the functions, most of the time (rather than work for all the functions, all the time...)&lt;br /&gt;
&lt;br /&gt;
Technically speaking, PML can infer an error called &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; when it encounters a program which, it thinks, may not terminate. Such an error cannot be captured: this is an error rather than an exception. The property we need to guarantee is that if PML doesn&#039;t infer the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; possible, then the program in question does indeed terminate. If the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; is possible for a terminating function, the user can still provide PML with a proof that this error is never raised. PML current syntax for that is &amp;lt;tt&amp;gt;[p proof ... ]&amp;lt;/tt&amp;gt; where &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; is a term and &amp;lt;tt&amp;gt;...&amp;lt;/tt&amp;gt; is a proof that &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; doesn&#039;t raise any exception nor error (this is the desired property for proofs).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.a - Core termination criterion&#039;&#039;&#039; (delivered 09/2010)&lt;br /&gt;
&lt;br /&gt;
This first test is now part of PML. Since primitive recursive function isn&#039;t enough in practice, even for proofs, a subtler and more powerfull termination criterion has been implemented. This is an extension of the &amp;quot;size change principle&amp;quot; of Lee, Jones and Ben-Amram [LJ01]. This test successfully checks termination for primitive recursion, lexicographic ordering and permutation of arguments and thus covers most simple practical cases. The implementation is quite similar to the original size-change principle, but the proof of correctness is surprisingly more difficult: see [Hyv10b].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.b - Improvement of the core termination criterion&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
The size-change principle is simple and powerful, but many cases occurring in practice aren&#039;t tagged as terminating. We plan to adapt to PML a termination criterion based on the technique of type-based termination, which allow for recursive calls through size preserving functions such as &amp;lt;tt&amp;gt;List.map&amp;lt;/tt&amp;gt;. There are several possibilities, ranging from simple systems such as the one developed by Abel (RAIRO&#039;04) [Abel04], Barthe et al (MSCS&#039;04) [Bar04] or Blanqui (RTA&#039;04, CSL&#039;05) [Bla04, Bla05c], to the very rich system of Blanqui and Riba (LPAR&#039;06) [BlR06]. In the latter, given for each function some formula in Presburger arithmetic describing how the size of the output is related to the size of the inputs (the correctness of which can be checked automatically), the termination follows from the fact that recursive calls are done on strictly decreasing arguments, using for instance lexicographic or multiset comparisons together with linear combinations of the arguments. Intermediate systems, such as the one of Barthe, Grégoire and Riba (CSL&#039;08) [BGR08] which is powerful but with a lower complexity than Presburger arithmetic, have also to be considered.&lt;br /&gt;
&lt;br /&gt;
This development looks rather orthogonal to the implemented criterion and might require small modification of other parts of PML in order to get the appropriate information. On a different level, slight extensions should be added to the existing criterion to enhance its complexity on some specific examples that are recognized as termination, but not in a reasonable time.&lt;br /&gt;
&lt;br /&gt;
This core termination needs to reach an acceptable compromise between power and simplicity. In particular, the most complex developments may not find their way into the core termination criteria, but rather be used in the next task...&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.c - Use of external provers&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
In order to circumvent the limitations of the core termination criterion, we propose to use external powerful termination provers like [http://aprove.informatik.rwth-aachen.de/ Aprove] or [http://colo6-c703.uibk.ac.at/ttt2/ TTT2] that implement and combine many other termination techniques. To this end, we can define translations from PML programs to one or more of the possible formats currently used in the [http://termination-portal.org/wiki/Termination_Competition annual international competition on termination] and in particular: first-order rewrite systems (TRS), dependency pair problems (DP problem), higher-order rewrite systems (HOTRS) or Haskell programs. In particular, we could reuse some of the techniques used for converting Haskell programs into first-order DP problems in [Gie06].&lt;br /&gt;
&lt;br /&gt;
But to which extent can we trust the results of these provers? Hopefully, now, many termination provers provide certificates in a format called [http://cl-informatik.uibk.ac.at/software/cpf/ CPF] that can be checked by certified, dedicated tools like [http://cl-informatik.uibk.ac.at/software/ceta/ CeTA], [http://color.inria.fr/ Rainbow] or [http://a3pat.ensiie.fr/ CiME3].&lt;br /&gt;
&lt;br /&gt;
The most pragmatic route is simply to trust those tools and concentrate on proving that the translation from (restricted) PML code to the input language is indeed correct. Of course, the ideal solution would be to be able to translate the external certificates into an equivalent PML program whose termination can be infered by the core criterion. The complexity of tools like [http://aprove.informatik.rwth-aachen.de/ Aprove] makes it look very difficult and it is probably hopeless to do that in a general manner.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.d - Modularity and termination&#039;&#039;&#039; (beginning 09/2013, never ending)&lt;br /&gt;
&lt;br /&gt;
The core termination prover does not use the definition of functions to prove their termination, but only information gathered from the typing constraints. When using external prover, for large development, one also would like to avoid sending a large piece of code to the external prover. &lt;br /&gt;
&lt;br /&gt;
Function such as &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; preserves the length of list. But the notion of length does not appear explcitely in the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. This means that the current core termination prover often can not prove termination of a function that use &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. It also means that you need to give the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; to an external tool. &lt;br /&gt;
&lt;br /&gt;
We would like to automatically compute some concise information about the size differences between input and output of program. This means that we would like to infer (when possible) a notion of &#039;&#039;size&#039;&#039; from the definition of a function.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Remark&#039;&#039;&#039;: The halting problem is undecidable, the available external tools for checking termination are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the termination checker.&lt;br /&gt;
&lt;br /&gt;
====Task 3 - compilation ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Wojciech Matyjewicz, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.a - A first compiler using LLVM&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012) LLVM is a compiler infrastructure providing many tools: compilation strategy, virtual instruction set, compiler infrastructure, tools to write high level virtual machines, etc. LLVM is very attractive, because it is rather simple to use (it even has an OCaml interface) and can compile for a bytecode interpreter, can be used as a JIT compiler or a standard compiler. Moreover, it support a lot of platforms. It also provide some optimizations, which is important. We think that writing a compiler, with no optimization, for PML using LLVM should not be too hard (this is important that this task be easy, because this is not really research ...)&lt;br /&gt;
&lt;br /&gt;
A polish phd student Wojciech Matyjewicz has started to work on this in december. He visited the LAMA during one week to start the project. It is important to note that he is a first year phd in Poland and the first year there is equivalent to our Master 2. Which means that Wojciech Matyjewicz is a potential candidate.&lt;br /&gt;
&lt;br /&gt;
Then, we would like to improve our compiler in various direction. We mention here the ones that are innovative in this domain (we should also consider more standard optimization, but we do not mention them specifically). &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.b - Representation of cartesian product and disjoint sum&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012 for product) PML allows only one kind of cartesian product which in general (because of multiple inheritance and implicit subtyping) must be represented as a table (hash-table or maps based on binary search trees). These can impact performance. We plan to generate extra constraints for each occurrence of a constructor of a cartesian product in a program. Then, solving this constraint in a way that maximize speed (or size) should allow for a representation of cartesian product that is more efficient than using, for instance, OCaml. The same kind of optimization (with a different optimization criterion) should be done for sum types and the implementation of pattern matching. This optimisation should be included in the first compiler because the implentation with tables is too costly for a temporary solution.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.c - Unboxing&#039;&#039;&#039; (depends on some parts of 3.b, beginning 1/2012, delivered 1/2013) In general, 32 bits integer and floating point number are boxed (that is represented by a pointer). This allows a more elegant language. This can lead to major impact on performance especially when arrays are involved. We think that constraint-checking is a good framework to propagate type information and allow efficient unboxing. Nevertheless, doing enough unboxing to try to match the performance of low level languages like C is very hard. We hope that we can reuse some of the work of task 3.b, because unboxing can be seen also as the optimization of the representation of a cartesian product with only one field.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.d - compilation of affectation (reference and arrays) and IO&#039;&#039;&#039; (depend upon 1.c, beginning 09/2012, delivered 03/2014) After adapting uniqueness typing to PML (task 1.c), we will be able to compile affectation and IO imperatively as in any imperative programming language.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.e - Garbage collection&#039;&#039;&#039; (beginning 01/2014, delivered 09/2014) For simplicity reasons, the first compiler will simply use Boehm&#039;s garbage collector. This garbage collector is relatively efficient and simple to use. However, Boehm&#039;s GC isn&#039;t optimised for the kind of allocations used in a functional language. Moreover, having a multithreaded GC could prove usefull in moder environment. We thus plan to replace Boehm&#039;s GC by a dedicated GC tuned for our purposes.&lt;br /&gt;
&lt;br /&gt;
Writing a GC that is both efficient and correct is not easy, and this sub-task is rather orthogonal to the PML language, which explains why it only comes later during the project. Nevertheless, we feel it is necessary to go through the trouble if we want to be as efficient (or even better, more efficient) than existing functional languages...&lt;br /&gt;
&lt;br /&gt;
====Task 4 - Automated reasoning====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Frédéric Blanqui&lt;br /&gt;
&lt;br /&gt;
Participants: Frédéric Blanqui, Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
The kernel of the proof engine will be based on completion techniques. Knuth-Bendix completion tries to transform a set of unoriented equations into a set of (inter-reduced and) convergent, that is, terminating and confluent, set of rewrite rules. It can therefore be used for proving that some equality is the equational consequence of some equational theory. Indeed, when an equational theory can be completed into a convergent rewrite system, two terms are equivalent in this equational theory if their normal form in the convergent rewrite systems are equal.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.a - Adaptation of the Knuth-Bendix completion algorithm to PML&#039;&#039;&#039; (already started, delivered 09/2015) As explained just before, Knuth-Bendix completion is based on rewriting. However, in PML, programs are not rewriting systems. We therefore need to adapt Knuth-Bendix completion. We need both generalization, to use the notion of constructor present in ML and take care of the higher-order nature of ML (even if we can not hope much here).&lt;br /&gt;
As said above, something is already implemented, but it is trivial because completely restricted to closed terms. A first version should be able at least to rewrite a closed term modulo some simple equational (and universal) theory. An important point here is to ensure termination&lt;br /&gt;
of this algorithm and even a low complexity. The price to pay, will be incompleteness. A lot of care should also be devoted to the correctness of the implementation, because like for task 3.a, the consistency of PML relies on it.&lt;br /&gt;
&lt;br /&gt;
This task in one of the major task for PML and a first version already exists, but is non terminating in presence of equalities between functions: if we have an equation like &#039;&#039;f = f o f&#039;&#039;, PML may use this equation has a definition of &#039;&#039;f&#039;&#039; and loop. For dealing with these cases, we are considering a fix which involves some notions similar to those of &#039;&#039;geometry of interaction&#039;&#039;. Another particular and very important case of universal equation that we should take into account is associativity and commutativity. It is indeed very important to ease proofs on integers (addition and multiplication are associative and commutative). To this end, we could reuse the [http://cime.lri.fr CiME] library.&lt;br /&gt;
&lt;br /&gt;
Note that this work could benefit to other projects and tools, like [http://moca.inria.fr/ Moca], a generator of construction functions for private data types with algebraic invariants, also based on completion, or Europa, a proof assistant based on the lambda-pi-calculus modulo rewriting developed by Gilles Dowek and [http://www.lix.polytechnique.fr/Labo/Mathieu.Boespflug/ Mathieu Boespflug]. Indeed, currently, Moca generates OCaml code without guarantee on its correctness. Using PML instead, Moca could also generate a proof of the correctness of the generated construction functions.&lt;br /&gt;
Then, later, when trying to prove the correctness of a function defined on this private date type, one can use the invariants satisfied by the values of the private data type as assumptions, since these invariants are satisfied by construction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.b - Use of external provers&#039;&#039;&#039; (beginning 03/2012, delivered 09/2015) Like for termination proofs, in order to increase the proving capacities of PML, we will provide a translation of PML proof goals into the [http://www.cs.miami.edu/~tptp/ TPTP standard format] of the CASC competition in order to be able to use external provers too, and in particular provers based on completion like [http://www.waldmeister.org/ Waldmeister], [http://cime.lri.fr/ CiME] or [http://cl-informatik.uibk.ac.at/mkbtt/ mkbTT] but not only. And possibly some certifying provers like [http://focal.inria.fr/zenon/ Zenon] based on tableaux or [http://alt-ergo.lri.fr/ Alter-Ego] based on SMT (SAT solver modulo theory).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Same remark than for termination&#039;&#039;&#039;: The problem is undecidable, the available external tools for automated reasonning are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the automated reasonning.&lt;br /&gt;
&lt;br /&gt;
====Task 5 - validation (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Christophe Mouilleron, Tom Hirschowitz.&lt;br /&gt;
&lt;br /&gt;
The validation requires to write numerous examples to check that we fulfill our main goal, which is that all programs (with or without proof) are written in the best possible way. This work being research, we think that it is important that any piece of code written in PML that does not look &#039;&#039;right&#039;&#039; is carefully examined to check that this is not due to a defect in language design.&lt;br /&gt;
&lt;br /&gt;
Christophe Mouilleron and Erik Martin-Dorel started to work on the axiomatisation of computer arithmetics within an ongoing PEPS project. This is a good test for PML and moreover a requirement &lt;br /&gt;
because we want PML to be a real programming language and thefore the limited arithmetic of processors (32 and 64 bits integer and floating point number) must be supported by PML. However, proving software using them is not trivial at all and Christophe Mouilleron member of the Arénaire team in ENS Lyon is a specialist in this domain.&lt;br /&gt;
&lt;br /&gt;
Tom Hirschowitz and Christophe Raffalli already started (and almost finished) a proof in PML that &lt;br /&gt;
categories, functors and natural transformations form a 2-category (this development is available in the example directory in the current version of PML). We plan to continue such abstract developments and we think that they could lead to interesting perspectives about the modularity of PML.&lt;br /&gt;
&lt;br /&gt;
More general code, including a standard library and some significant mathematics should be developed (there is already around 10.000 lines of PML code in the current distribution). Moreover, we started to port Pierce et al.&#039;s course, in Coq, on software foundations (http://www.cis.upenn.edu/~bcpierce/sf/), to PML. The first three files are translated and there remain a dozen of files of around 2500 lines to translate. This is a major work, but would provide a very good test for PML, and a good tutorial.&lt;br /&gt;
&lt;br /&gt;
This task should deliver at least 100.000 lines of PML code to have&lt;br /&gt;
a sufficient corpus to say in which respect we fulfilled our goals.&lt;br /&gt;
&lt;br /&gt;
==== Task 6 - Optimisation of PML (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: C. Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: All (anyone could optimize the part of PML he was involved in).&lt;br /&gt;
&lt;br /&gt;
Some of the choice in the design of PML involve rather complex algorithm. Notably, this is the case of the constraint checking algorithm and completion procedure. The first implementation is not trivial but not optimized either. And very often, we have discoverd and will continue to discover that PML is too slow. This goal of this trasversal task is to ensure that PML is usable. &lt;br /&gt;
&lt;br /&gt;
Currently, some optimisations were already added. For instance, PML uses a sat solver for various &lt;br /&gt;
tasks: completeness and usefulness of cases in pattern matching and dealing with negative &lt;br /&gt;
hypothesis (like &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is not equal to &amp;lt;tt&amp;gt;S[x]&amp;lt;/tt&amp;gt;) in the completion procedure. Improving the sat solver using J.C. Filliâtre work [] and simploifying the formula before giving them to the sat solver were a major improvement.&lt;br /&gt;
&lt;br /&gt;
A lot of other optimisations are planned: &lt;br /&gt;
* The graph used to encode the typing constraints should probably be reduced (that is we should compute its transitive reduction). &lt;br /&gt;
* The completion procedure stores a set of terms of the language and we need a fast way to recover the set of all term using a given sub-term. The current implementation is too naïve. &lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
=== Planning of tasks, deliverables and milestones ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The following diagram represents the summary of the tasks and subtasks, together with the intended planning:&lt;br /&gt;
&lt;br /&gt;
[[Image:pml-gantt.png]]&lt;br /&gt;
&lt;br /&gt;
==Data management, data sharing, intellectual property and results exploitation==&lt;br /&gt;
&lt;br /&gt;
Results in each of the tasks will be published in journals (APAL, TCS, ...) and international conferences as usual (LICS, TLCA, CSL, CIE, ...).&lt;br /&gt;
&lt;br /&gt;
PML language is already distributed as open source software under the Cecill-B license. We think that for such a research platform, this is the only possible way to ensure that people will try it. As soon as a first compiler is available, we plan to produce easy-to-install packages, at least for some well-known Linux distributions (Debian and its derivatives seem a good choice).&lt;br /&gt;
&lt;br /&gt;
==Consortium organization and description==&lt;br /&gt;
&lt;br /&gt;
===Relevance of the partner for the project===&lt;br /&gt;
&lt;br /&gt;
This project involve only one partner, the LAMA (UMR 5127), where the coordinator of the project already developed the proof assistant PhoX. The main characteristic of PhoX is to be rather simple to use due to a set of tactics which is limited (less than 20 for the principal ones), but powerful. Moreover, tactics are extensible by &#039;&#039;incorporating theorems&#039;&#039; inside the tactics.&lt;br /&gt;
&lt;br /&gt;
Clearly, this means that efficiency was the main goal of PhoX. Unfortunately, like all tactical theorem prover, PhoX proofs are not readable. After a few attempts with a Mizar-like mode for PhoX, Christophe Raffalli decided to move to a new theorem prover, starting from scratch.&lt;br /&gt;
&lt;br /&gt;
Pierre Hyvernat is also in Chambery and the second developer of PML (he wrote the current termination checker). Tom Hirshowitz has some prior experience in his phd about the compilation of functional languages. At ENS Lyon, which is very near to Chambéry, Alexandre Miquel is a specialist of consistency proof for logical framework. Therefore, Chambery is the very natural partner for this project.&lt;br /&gt;
&lt;br /&gt;
===Qualification of the project coordinator and members===&lt;br /&gt;
&lt;br /&gt;
The coordinator and various members of the project comes from various horizon (see section 7), but they have a common background around the use and development of programming language and/or formal methods. We think that this variety, the small number of members, should allow for good communication and should be very fruitful. &lt;br /&gt;
&lt;br /&gt;
We think, that compared with the development of PML by Christophe Raffalli alone, such a team should speed up the development of PML approximately by a factor 3, making it possible to deliver a very innovative and useful tool at the end of the project. The lack of support for such a team would certainly limit the tool to an experimental toy with many development only partially (or even not at all) integrated in the project.&lt;br /&gt;
&lt;br /&gt;
Christophe Raffalli will also ask for delegations during the project to be able to spend even more time on it.&lt;br /&gt;
&lt;br /&gt;
==Scientific justification of requested budget==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Meetings (total 9720€ per year)====&lt;br /&gt;
 &lt;br /&gt;
Two meetings and one workshop per year, 3 days each, for 7 people. Each meeting costs&lt;br /&gt;
1 train ticket in France, 3 days and 2 nights:&lt;br /&gt;
3*7*(100 + 3*20 + 2*80) = 6720€. &lt;br /&gt;
&lt;br /&gt;
For the workshop, we have to invite 2 to 3 guests. Some may come from foreign country and we estimate the cost&lt;br /&gt;
to 3000€ per year. Which mean a total of 9720€ per year.&lt;br /&gt;
&lt;br /&gt;
====Visits (total 10000€)====&lt;br /&gt;
&lt;br /&gt;
We think that this is very important for this project to interact with other project.&lt;br /&gt;
For instance, Andreas Abel came to visit Chambéry in 2010 for two weeks financed by our PEPS&lt;br /&gt;
project and during this time induced an important bootstrap to the implementation of the termination checker &lt;br /&gt;
[Hyv10b] and contributed a non trivial example with a proved implentation of left-leaning red-black trees.&lt;br /&gt;
&lt;br /&gt;
We want to continue such interaction. Andreas Abel already agreed as well as Joe Wells for discusion about error reporting and , Assia Mahboubi for complex proofs involving the reflexion principle. Many other discussion would be profitable about PML runtime (with multithreading ?), interaction with external tools (termination checker or automated theorem prover), &lt;br /&gt;
uniqueness typing (meeting with people already using such technics), ...&lt;br /&gt;
&lt;br /&gt;
We plan around 4 short visits of one or two weeks from people outside the project to Chambéry and the same amount for short visit in the other direction. This means around 12 weeks per year with 8 travels for a cost of 500€ per week (x12) plus in average (depending if we use plane or train) the same amount for each travel (x8), with a total of 10000€ per year.&lt;br /&gt;
&lt;br /&gt;
====Conferences (total 9600€ per year)====&lt;br /&gt;
 &lt;br /&gt;
The members of the ANR will submit papers to international conferences and&lt;br /&gt;
journals and attend to specialized workshop. We have 2.5 person/year on the project with means &lt;br /&gt;
around 3 international conferences or workshop per year (estimated cost 2000€) and one national conference or workshop per year (estimated cost 1200€)&lt;br /&gt;
&lt;br /&gt;
====Master internships (total 1500€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We plan to host around four master internships in good conditions (possibly&lt;br /&gt;
followed by PhD studentships not financed by the ANR): one per year with a total cost of&lt;br /&gt;
6000€ (1500€ each: 300€ for travel and 200€ per month for an accommodation at&lt;br /&gt;
the CROUS).&lt;br /&gt;
&lt;br /&gt;
====Computers (total 2000€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We consider that the ANR project has to participate in the renewal of the&lt;br /&gt;
computers of its participants. The lifetime of a computer being 4 years and&lt;br /&gt;
the total number of month for permanent members of the project being 112, we&lt;br /&gt;
think that we should pay for 4 computers with an average value of 2000€ each&lt;br /&gt;
(we need powerful computers and laptops, because automated reasoning requires&lt;br /&gt;
a lot of computations and memory).&lt;br /&gt;
&lt;br /&gt;
====Human resources financed by the ANR (1 PhD student, 2 two years postdocs and 4 month of invited professor)====&lt;br /&gt;
 &lt;br /&gt;
This project involves many tasks and 7 members. However, all members&lt;br /&gt;
apart from the coordinator and Pierre Hyvernat can only devote 2-3 month per year to this project&lt;br /&gt;
(they are involved in other ongoing research). Although this is far from&lt;br /&gt;
negligible, we think that we will need more human power: we estimate that 1&lt;br /&gt;
PhD and 2 postdocs are reasonable. &lt;br /&gt;
&lt;br /&gt;
We also consider that one year post-doc are not sufficient, because the time need to &lt;br /&gt;
understand the existing code base is long and the student has both to write code and &lt;br /&gt;
publish its result. Moreover, the code produced by the student will not be an experimental&lt;br /&gt;
code to support its publication, but code which should remain in the project and be maintened by &lt;br /&gt;
other member of the project. In one year, this seems impossible to achieve.&lt;br /&gt;
&lt;br /&gt;
Moreover, as mentioned in the section about visits, we would like to have 1 month per year of invited professor.&lt;br /&gt;
&lt;br /&gt;
This would give a total 88 months (4 month invited, 36 for the PhD and 48 for the 2 postdocs)&lt;br /&gt;
To be compared with the total of 104/112 month not payed by the ANR. We consider that this is a good balance.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 308589€.&lt;br /&gt;
&lt;br /&gt;
====Human resources not financed by the ANR====&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! month/year&lt;br /&gt;
! percentage&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Raffalli&lt;br /&gt;
| 10&lt;br /&gt;
| 85%&lt;br /&gt;
|-&lt;br /&gt;
| Frédéric Blanqui&lt;br /&gt;
| 4&lt;br /&gt;
| 25%&lt;br /&gt;
|-&lt;br /&gt;
| Emmanuel Chailloux&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Tom Hirshowitz&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Pierre Hyvernat&lt;br /&gt;
| 6&lt;br /&gt;
| 50%&lt;br /&gt;
|-&lt;br /&gt;
| Alexandre Miquel&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Mouilleron&lt;br /&gt;
| 0/2&lt;br /&gt;
| 0/15%&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total per year&#039;&#039;&#039;&lt;br /&gt;
| 26/28&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total for 4 year&#039;&#039;&#039;&lt;br /&gt;
| 104/112&lt;br /&gt;
| &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Remark: the situation of Christophe Mouilleron is unknown next year. If it is possible he will &lt;br /&gt;
continue is work on PML started with the PEPS for around 2 month per year. But if it is not possible, &lt;br /&gt;
or if he is selected for the post-doc position, then we should not count it. We used the worst case&lt;br /&gt;
on the website.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 350333€ snas ternir compte de Christophe Mouilleron.&lt;br /&gt;
&lt;br /&gt;
==Annexes==&lt;br /&gt;
&lt;br /&gt;
===CV, Resume of all project members===&lt;br /&gt;
&lt;br /&gt;
==== Christophe Raffalli (project coordinator) ====&lt;br /&gt;
&lt;br /&gt;
Age 41, MCF at the LAMA (UMR 5127) since September 1997.&lt;br /&gt;
&lt;br /&gt;
After his PhD in Paris VII (defended in February 1994), Christophe Raffalli spent 1 and a half year at the LFCS in Edinburgh, 2 years at Chalmers university in Göteborg (post-doc of the TYPES European project) and 1 year as ATER in Créteil University.&lt;br /&gt;
&lt;br /&gt;
Research administration: For ten years, the LAMA was sub-site of the Paris VII site inside the TYPES project which was renewed several times and Christophe Raffalli was the coordinator for this sub-site. Currently the project is not financed by the E.U. Nevertheless, Christophe Raffalli is in charge of the organization of the next TYPES meeting in Aussois in May 2009.&lt;br /&gt;
&lt;br /&gt;
His research interests include:&lt;br /&gt;
&lt;br /&gt;
* theory and implementation of proof assistants,&lt;br /&gt;
* proof theory,&lt;br /&gt;
* implementation of programming languages (especially type-systems).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Raf10b] &#039;&#039;Realizability for programming languages&#039;&#039; (submitted, available as hal-00474043)&lt;br /&gt;
&lt;br /&gt;
* [Raf08a] &#039;&#039;PML and strong normalisation&#039;&#039; conference at the Types workshop, April 2008, Turino, Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf07b] &#039;&#039;PML: a new proof assistant&#039;&#039; conference at the Types workshop, may 2007, Cividale del Friuli (Udine), Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf06a] &#039;&#039;Realizability of the axiom of choice in HOL (An analysis of Krivines&#039;s work)&#039;&#039; with Frédéric Ruyer in Fundamenta Informaticae (2006)&lt;br /&gt;
&lt;br /&gt;
* [Raf05a] &#039;&#039;PhoX&#039;&#039; with Paul Rozière in The seventeen provers of the World, Freek Wiedijk (editor) LNAI 3600 pages 67-71&lt;br /&gt;
&lt;br /&gt;
* [Raf03b] &#039;&#039;System ST&#039;&#039; Schedae Informatica, proceedings of the Chambery-Krawow-Lyon Workshop, Vol. 12, pages 97-112 (June 2003)&lt;br /&gt;
&lt;br /&gt;
* [Raf02c] &#039;&#039;Getting results from programs extracted from classical proofs&#039;&#039;, TCS 2004, volume 323, pages 49-70&lt;br /&gt;
&lt;br /&gt;
* [Raf02b] &#039;&#039;System ST, beta-reduction and completeness&#039;&#039;, presented at LICS 2003, publication IEEE, pages 21-32&lt;br /&gt;
&lt;br /&gt;
* [Raf02a] &#039;&#039;Computer Assisted Teaching in Mathematics&#039;&#039;, with René David, to appear in the proceedings of the Workshop on 35 years of Automath (April 2002, Edingurgh)&lt;br /&gt;
&lt;br /&gt;
* [Raf01d] &#039;&#039;System ST, towards a Type System for Extraction and Proof of Programs&#039;&#039;, Archive for Pure and Applied Logic, 2003, volume 122, pages 107-130&lt;br /&gt;
&lt;br /&gt;
* [Raf01c] &#039;&#039;Apprentissage du raisonnement assité par ordinateur&#039;&#039;, avec René David, Quadrature numéro 45, printemps 2002, pages 25-36). Version courte parue dans la gazette de la SMF, avril 2002, numéro 92, pages 48-56&lt;br /&gt;
&lt;br /&gt;
==== Frederic Blanqui (INRIA, Rocquencourt) ====&lt;br /&gt;
&lt;br /&gt;
Age 38, permanent full-time researcher at [http://www.inria.fr INRIA].&lt;br /&gt;
&lt;br /&gt;
Frederic Blanqui is expert in the following areas:&lt;br /&gt;
* type theory,&lt;br /&gt;
* rewriting theory,&lt;br /&gt;
* termination,&lt;br /&gt;
* functional programming,&lt;br /&gt;
* proof assistants,&lt;br /&gt;
* and formal certification of program properties.&lt;br /&gt;
&lt;br /&gt;
Since September 2008, he is INRIA researcher at [http://liama.ia.ac.cn LIAMA], the Sino-French Laboratory in Computer Science, Automation and Applied Mathematics.&lt;br /&gt;
&lt;br /&gt;
Between 2003 and 2008, he was INRIA researcher at [http://www.loria.fr LORIA], Nancy, in the Protheo research team led by Pr Claude Kirchner, focusing on the use of rewriting techniques for programming, as well as specifying and proving program properties.&lt;br /&gt;
&lt;br /&gt;
Since 2004, he is leading the [http://color.inria.fr CoLoR] project which aims at providing tools for automatically certifying the termination of programs. Since 2007, CoLoR is the best certification back-end in the international [http://termination-portal.org/wiki/Termination_Competition competition on certified termination provers].&lt;br /&gt;
&lt;br /&gt;
In 2007 and 2008, he led the INRIA [http://quotient.loria.fr/ Quotient] project which aims at extending the [http://caml.inria.fr OCaml] programming language with types whose values automatically satisfy equational invariants using the [http://moca.inria.fr Moca] tool.&lt;br /&gt;
&lt;br /&gt;
He supervised 2 master thesis and 3 PhD students on the extension of type theory with decision procedures, the termination of typed higher-order rule-based programs, and the certification of termination proofs.&lt;br /&gt;
&lt;br /&gt;
He did his PhD with Pr Jean-Pierre Jouannaud at University Paris Sud between October 1998 and September 2001 on the combination of type theory and rewriting theory.&lt;br /&gt;
&lt;br /&gt;
Between October 2001 and August 2002, he worked on the certification of cryptographic protocols with Pr Larry Paulson at Cambridge, UK.&lt;br /&gt;
&lt;br /&gt;
Between September 2002 and September 2003, he worked at Ecole Polytechnique in the [http://coq.inria.fr Coq] development team on the extension of the proof assistant Coq with rewriting.&lt;br /&gt;
&lt;br /&gt;
More details on his activities and publications can be found on his [http://www-rocq.inria.fr/~blanqui/ web page] and in his [http://www-rocq.inria.fr/~blanqui/divers/cv.pdf CV].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
International journals with reading committee: 7&lt;br /&gt;
&lt;br /&gt;
International conferences with reading committee: 15&lt;br /&gt;
&lt;br /&gt;
Other publications (thesis, workshops, invited papers, reports, etc.): 15&lt;br /&gt;
&lt;br /&gt;
Prizes: 2001 [http://www.specif.org/ SPECIF] Award for his PhD thesis by the French national society of teachers and researchers in computer science; and 2001 Kleene Award for the best young researcher paper at the IEEE Symposium on Logic in Computer Science ([http://www2.informatik.hu-berlin.de/lics/ LICS]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Five most significant publications in the last 5 years:&lt;br /&gt;
&lt;br /&gt;
* [Bla11] F. Blanqui and A. Koprowski. &#039;&#039;CoLoR: a Coq library on well-founded rewrite relations and its application to the automated verification of termination certificates&#039;&#039;. To appear in Mathematical Structures in Computer Science.&lt;br /&gt;
&lt;br /&gt;
* [BRK10] F. Blanqui, C. Riba and C. Kirchner. &#039;&#039;On the confluence of lambda-calculus with conditional rewriting&#039;&#039;. Theoretical Computer Science 411(37), p. 3301-3327.&lt;br /&gt;
&lt;br /&gt;
* [BR09] F. Blanqui and C. Roux. &#039;&#039;On the relation between sized-types based termination and semantic labelling&#039;&#039;. CSL&#039;09. LNCS 5771.&lt;br /&gt;
&lt;br /&gt;
* [BJS08] F. Blanqui, J.-P. Jouannaud and P.-Y. Strub. &#039;&#039;From formal proofs to mathematical proofs: a safe, incremental way for building in first-order decision procedures&#039;&#039;. TCS&#039;08. IFIP 273.&lt;br /&gt;
&lt;br /&gt;
* [BHW07] F. Blanqui, Thérèse Hardin and Pierre Weis. &#039;&#039;On the Implementation of Construction Functions for Non-free Concrete Data Types&#039;&#039;. ESOP 2007: 95-109.&lt;br /&gt;
&lt;br /&gt;
==== Emmanuel Chailloux (LIP6, Paris) ====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Age 51,  full professor at the University &lt;br /&gt;
Pierre et Marie Curie ([http://www.upmc.fr UPMC - Paris 6]) in Paris France, &lt;br /&gt;
and since October 2006  researcher at the &lt;br /&gt;
[http://www.lip6.fr LIP6] computer science laboratory (UMR 7606), &lt;br /&gt;
in the &amp;quot;Algorithms, Programs and Resolution&amp;quot; team ([http://www-apr.lip6.fr APR]).&lt;br /&gt;
&lt;br /&gt;
His research work is related to design and implementation of programming languages : &lt;br /&gt;
* semantics, &lt;br /&gt;
* types systems, &lt;br /&gt;
* runtime implementation, &lt;br /&gt;
* multicores. &lt;br /&gt;
Most of the recent publications relate to safety-critical software development.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Recent publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[VWC-2011] Vaugon B., Wang P., Chailloux E. &#039;&#039; Les microcontrôleurs&lt;br /&gt;
PIC programmés en Objective Caml&#039;&#039;. Journées des Langages Applicatifs&lt;br /&gt;
(JFLA&#039;2011), janvier 2011.&lt;br /&gt;
&lt;br /&gt;
[WJC-2010] Wang P., Jonquet A., Chailloux E. &#039;&#039;Non-Intrusive&lt;br /&gt;
Structural Coverage for Objective Caml&#039;&#039;.  5th Workshop on Bytecode&lt;br /&gt;
Semantics, Verification, Analysis and Transformation (Bytecode), 2010.&lt;br /&gt;
&lt;br /&gt;
[PAMCCWMC-2009] Pagano B., Andrieu O., Moniot T., Canou B., Chailloux&lt;br /&gt;
E., Wang P., Manoury P., Colaço J.-L. &#039;&#039;Experience Report: Using&lt;br /&gt;
Objective Caml to develop safety-critical embedded tool in a&lt;br /&gt;
certificaiton framework&#039;&#039;.  International Conference of Functional&lt;br /&gt;
Programming (ICFP&#039;09), 2009.&lt;br /&gt;
&lt;br /&gt;
[CBC-2008] Canou B., Balat V., Chailloux E. &#039;&#039;O&#039;Browser : Objective&lt;br /&gt;
Caml on browsers&#039;&#039;. The 2008 ACM SIGPLAN Workshop on ML, 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;HIRONDML: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 2008, 55--69.&lt;br /&gt;
&lt;br /&gt;
[PACCCMW-2008] Pagano B., Andrieu O., Canou B., Chailloux E., Colaço J.-L., Moniot T., Wang P. &lt;br /&gt;
&#039;&#039;Certified development tools implementation in objective caml.&#039;&#039;  &lt;br /&gt;
International Symposium on Practical Aspects of Declarative Languages (PADL 08), 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;Hirondml: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 (2008) 55-69&lt;br /&gt;
&lt;br /&gt;
[HMC-2007] Henry G., Mauny M., Chailloux E. &#039;&#039;Typer la désérialisation&lt;br /&gt;
sans sérialiser les types&#039;&#039;. Technique et Science Informatiques 26, 9&lt;br /&gt;
(2007) 1067-1090.&lt;br /&gt;
&lt;br /&gt;
[CM-2006] Chailloux E., Mauny M. &#039;&#039;Programmation fonctionnelle&#039;&#039;.&lt;br /&gt;
Encyclopédie de l&#039;informatique et des systèmes d&#039;information (2006)&lt;br /&gt;
1016--1027.&lt;br /&gt;
&lt;br /&gt;
==== Tom Hirschowitz (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
34 ans, CR CNRS (informatique) , LAMA&lt;br /&gt;
&lt;br /&gt;
* 2007         CR CNRS au LAMA (UMR 5127) à Chambéry&lt;br /&gt;
* 2004-2007    CR CNRS au LIP (UMR5668) à Lyon&lt;br /&gt;
* 2003-2004    ATER, équipe Plume, LIP, ENS Lyon&lt;br /&gt;
* 2000-2003    Doctorat (dir.: X. Leroy, INRIA Rocquencourt, projet Cristal)&lt;br /&gt;
* 1999-2000    DEA à Paris 7&lt;br /&gt;
* 1996-2000    Ecole Nationale des Ponts et Chaussées&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;10 publications dans des revues et conférences internationales&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;publications choisies&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
# T. Hirschowitz, X. Leroy, and J. B. Wells. Compilation of extended recursion in call-by-value functional languages, PPDP 2003. Version journal dans Higher-Order and Symbolic Computation 22-1. 2009.&lt;br /&gt;
# R. Garner, T. Hirschowitz, and A. Pardon. Variable Binding, Symmetric Monoidal Closed Theories and Bigraphs. CONCUR&#039;09. 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. Contraction-free Proofs and Finitary Games for Linear Logic. MFPS, 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. A Theory for Game Theories. FSTTCS, 2007.&lt;br /&gt;
# T. Hirschowitz, X. Leroy. Mixin Modules in a Call-by-Value Setting, ESOP, 2002, journal version in ACM Transactions on Programming Languages and Systems, 2005.&lt;br /&gt;
&lt;br /&gt;
==== Pierre Hyvernat (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
Age 30, &amp;quot;maître de conférences&amp;quot; at the Université de Savoie (in Chambéry) since September 2006, member of the [http://www.lama.univ-savoie.fr LAMA].&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2005, under the supervision of Thierry Coquand (Chalmers, Göteborg, Sweden) and Thomas Ehrhard (at the time, IML, Luminy, Marseille, France)&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include&lt;br /&gt;
* denotational semantics,&lt;br /&gt;
* type theory and constructive mathematics.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Hyv10b] &#039;&#039;The Size-Change Termination Principle for Constructor Based Languages&#039;&#039; (hal-00547440, submitted)&lt;br /&gt;
&lt;br /&gt;
* [HHy06] with P. Hancock: &#039;&#039;Programming Interfaces and Basic Topology&#039;&#039;. &amp;quot;Annals of Pure and Applied Logic&amp;quot;, volume 137, January 2006,&lt;br /&gt;
&lt;br /&gt;
* [Hyv05] &#039;&#039;Synchronous Games, Simulations and lambda-calculus&#039;&#039;, proceedings of the &amp;quot;GaLoP&amp;quot; workshop, ETAPS 2005. (journal version submitted to Annals of Pure and Applied Logic),&lt;br /&gt;
&lt;br /&gt;
* [Hyv04] &#039;&#039;Predicate Transformers and Linear Logic: yet another Denotational Model&#039;&#039;, Lecture Notes in Computer Science, vol. 3210, September 2004.&lt;br /&gt;
&lt;br /&gt;
==== Alexandre Miquel (PPS, Paris 7) ====&lt;br /&gt;
&lt;br /&gt;
Age 37, &amp;quot;maître de conférences&amp;quot; at the Université Paris-Diderot (Paris 7) since September 2003, member of [http://www.pps.jussieu.fr/ PPS]. Currently CNRS research associate (&amp;quot;délégation&amp;quot;) in the Plume team at the LIP (ENS Lyon) since September 2008.&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2001, under the supervision of Hugo Herbelin (INRIA/LIX) in the Coq team (now TypiCal).&lt;br /&gt;
&lt;br /&gt;
From October 2001 to August 2002 he was postdoc in the Chalmers Institute of Technology (Göetborg, Sweden) under the supervision of Thierry Coquand, and from September 2002 to August 2003 he was &amp;quot;ATER&amp;quot; at the LRI (Orsay).&lt;br /&gt;
&lt;br /&gt;
He is a specialist of the models of type theory (especially the calculus of constructions) and of the correspondence between set theory and type theory. His research interests also include:&lt;br /&gt;
* logic, proof-theory, rewriting,&lt;br /&gt;
* denotational semantics (set- and domain-theoretic),&lt;br /&gt;
* realizability in classical logic.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
His most significant publications are:&lt;br /&gt;
&lt;br /&gt;
* [Miq07] &#039;&#039;Classical program extraction in the calculus of constructions&#039;&#039; (CSL&#039;07),&lt;br /&gt;
&lt;br /&gt;
* [Miq06] with A. Arbiser and A. Ríos. &#039;&#039;A lambda-calculus with constructors&#039;&#039; (RTA&#039;06),&lt;br /&gt;
&lt;br /&gt;
* [Miq04] &#039;&#039;Lambda-Z: Zermelo&#039;s Set Theory as a PTS with 4 Sorts&#039;&#039; (TYPES&#039;04),&lt;br /&gt;
&lt;br /&gt;
* [Miq03] &#039;&#039;A Strongly Normalising Curry-Howard Correspondence for IZF Set Theory&#039;&#039; (CSL&#039;03),&lt;br /&gt;
&lt;br /&gt;
* [Miq00] &#039;&#039;A Model for Impredicative Type Systems with Universes, Intersection Types and Subtyping&#039;&#039; (LICS&#039;00).&lt;br /&gt;
&lt;br /&gt;
==== Christophe Mouilleron (LIP, ENS de Lyon) ====&lt;br /&gt;
&lt;br /&gt;
Age 26, PhD student in the Arenaire team at the LIP (ENS de Lyon) since September 2008. He works under the supervision of Claude-Pierre Jeannerod (INRIA/LIP) and Gilles Villard (CNRS/LIP).&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include :&lt;br /&gt;
* computer arithmetic,&lt;br /&gt;
* code generation,&lt;br /&gt;
* formal proof of numerical properties in programs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [MouRev10] C. Mouilleron and G. Revy. &#039;&#039;Automatic Generation of Fast and Certified Code for Polynomial Evaluation.&#039;&#039; (submitted, available as ensl-00531721)&lt;br /&gt;
&lt;br /&gt;
* [JeaMou10] C.-P. Jeannerod and C. Mouilleron. &#039;&#039;Computing Specified Generators of Structured Matrix Inverses.&#039;&#039; (ISSAC&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [BJJK+10] C. Bertin, C.-P. Jeannerod, J. Jourdan-Lu, H. Knochel, C. Monat, C. Mouilleron, J.-M. Muller, and G. Revy. &#039;&#039;Techniques and tools for implementing IEEE 754 floating-point arithmetic on VLIW integer processors.&#039;&#039; (PASCO&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [LTdD+10] V. Lefèvre, P. Théveny, F. de Dinechin, C.-P. Jeannerod, C. Mouilleron, D. Pfannholzer, and N. Revol. &#039;&#039;LEMA : Towards a Language for Reliable Arithmetic.&#039;&#039; (PLMMS&#039;10)&lt;br /&gt;
&lt;br /&gt;
===Relevant publications by non participants to the project ===&lt;br /&gt;
&lt;br /&gt;
Here are some publication or resources of interest for the project:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Laguage design and theory:&#039;&#039;&#039;&lt;br /&gt;
* [SOW97] Martin Sulzmann, Martin Odersky, Martin Wehr, &#039;&#039;Type inference with constrained types&#039;&#039;, TAPOS, 1997.&lt;br /&gt;
* [HW04] Christian Haack and J. B. Wells, &#039;&#039;Type error slicing in implicitly typed higher-order languages&#039;&#039;, Sci. Comput. Programming, 50:189-224, 2004.&lt;br /&gt;
* [Ruy06] Frédéric Ruyer, &#039;&#039;Preuves, types et sous-type&#039;&#039;, phd 2006 directed by C. Raffalli.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Termination:&#039;&#039;&#039;&lt;br /&gt;
* [LJ01] Lee, Jones, et al. &#039;&#039;The size-change principle for program termination&#039;&#039; - ACM SIGPLAN Notices - 2001&lt;br /&gt;
* [Abel04] Andreas Abel, &#039;&#039;Termination Checking with Types&#039;&#039; ,Special Issue: Fixed Points in Computer Science (FICS&#039;03 and RAIR&#039;04)&lt;br /&gt;
* [Bar04]   G. Barthe, M. J. Frade  and E. Giménez, L. Pinto and T. Uustalu, &#039;&#039;Type-Based Termination of Recursive Definitions&#039;&#039;, 2004, Mathematical Structures in Computer Science.&lt;br /&gt;
* [Gie06] J. Giesl, S. Swiderski, P. Schneider-Kamp, and R. Thiemann &#039;&#039;Automated Termination Analysis for Haskell: From Term Rewriting to Programming Languages&#039;&#039;, Proceedings of the 17th International Conference on Rewriting Techniques and Applications (RTA-06), Lecture Notes in Computer Science 4098.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;the Clean language:&#039;&#039;&#039;&lt;br /&gt;
* [AGR92] Peter Achten, John van Groningen and Rinus Plasmeijer (1992). &#039;&#039;High-level specification of I/O in functional languages&#039;&#039;, Proc. of the Glasgow workshop on Functional programming, ed. J. Launchbury and P. Sansom, Ayr, Scotland, Springer-Verlag, Workshops in Computing, pp. 1-17.&lt;br /&gt;
* [AcP95] Peter Achten and Rinus Plasmeijer (1995). &#039;&#039;The Ins and Outs of CONCURRENT CLEAN I/O&#039;&#039;, Journal of Functional Programming, 5, 1, pp. 81-110.&lt;br /&gt;
* [AcP97] Peter Achten and Rinus Plasmeijer (1997). &#039;&#039;Interactive Functional Objects in CLEAN&#039;&#039;, Proc. of the 1997 Workshop on the Implementation of Functional Languages (IFL&#039;97), ed. K. Hammond Davie, T., and Clack, C., St.Andrews, Scotland,&lt;br /&gt;
* [VPA07] Edsko de Vries, Rinus Plasmeijer, and David M. Abrahamson, &#039;&#039;Uniqueness Typing Simplified, by Edsko de Vries&#039;&#039;,&lt;br /&gt;
* [http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf the language report] by Rinus Plasmeijer and Marko van Eekelen,&lt;br /&gt;
* [http://clean.cs.ru.nl/ the language homepage].&lt;br /&gt;
&lt;br /&gt;
===Involvement of project participants to other grants, contracts, etc …===&lt;br /&gt;
&lt;br /&gt;
* Emmanuel Chailloux is member of the ANR PWD (&amp;quot;Programmation du Web Diffus&amp;quot;), whose leader is Manuel Serrano (Inria), and the FUI [http://opengpu.net/ OpenGPU project].  &lt;br /&gt;
* Tom Hishowitz is involved in the ANR PiCoq the ANR proposals RÉCRÉ and CATHRE.&lt;br /&gt;
* Pierre Hyvernat is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Alexandre Miquel is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Christophe Raffalli is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
&lt;br /&gt;
Remark: the interaction with PML and RÉCRÉ is natural because the proof technics used for ensuring some of the properties of the language PML is réalizability which is one of the théma of the ANR proposal RÉCRÉ.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5081</id>
		<title>ANR PML</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5081"/>
		<updated>2011-01-13T11:15:19Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Task 5 - validation (transverse task) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;URL of PML project: &amp;lt;tt&amp;gt;http://lama.univ-savoie.fr/tracpml&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Context and positioning of the proposal==&lt;br /&gt;
&lt;br /&gt;
Ever since FORTRAN appeared fifty years ago, programming languages have been evolving rapidly. These languages now include more and more sophisticated concepts like &amp;quot;objects&amp;quot;, &amp;quot;type inference&amp;quot;, &amp;quot;modules&amp;quot;... However, this richness is also what makes it more and more complex to train programmers and makes it difficult for them to keep up with the innovations and changes in programming languages.&lt;br /&gt;
&lt;br /&gt;
Another orthogonal phenomenon is the emergence of formal methods used in conjunction with various programming languages to test, check or prove software. This introduces another layer to languages in order to write specifications, and sometimes yet another one for proofs. Learning a programming language together with the associated specification/proof languages can take an important effort.&lt;br /&gt;
&lt;br /&gt;
Projects such as [http://www.cs.utexas.edu/users/moore/acl2/ ACL2], the successor of  [http://www.cs.utexas.edu/users/boyer/ftp/nqthm nqthm, the Boyer-Moore theorem prover] uses a rather simple language (namely LISP) both as a programming language and specification language, allowing to keep a unity in the system. Unfortunately, LISP is somewhat limited both as a programming language (no good treatment of sum type, no module system) and a specification language (very limited quantification). Moreover, LISP has no compile-time type-checking, which has proved very useful to detect bugs and automatically assert properties.&lt;br /&gt;
&lt;br /&gt;
The aim of this project is to build a very powerful language (with no loss of expressive power compared to state of the art languages) based on a very small number of simple features. We think this will be possible thanks to recent progress both in the semantics of programming languages and the apparition of new algorithms for type inference based on constraints-solving. In fact, we propose in [RAF10b] an innovative concept derived from the later to enable this: constraints-checking.&lt;br /&gt;
&lt;br /&gt;
Moreover, the language will be used not only as a programming language and a specification language (like in ACL2), but also as the proof language. This is natural for an ML-like language because pattern-matching is a natural and powerful way to make a proof by case analysis. This also means that our tool will follow the &#039;&#039;KISS&#039;&#039; philosophy: relatively few (unified) features, yet powerful.&lt;br /&gt;
&lt;br /&gt;
The idea of a new language arose from the discovery of a new typing algorithm [RAF10b] whose implementation gave birth to a first implementation of PML (Proved ML) by Christophe Raffalli. This implementation is already available from [http://www.lama.univ-savoie.fr/~pml the web page of the language]. However, turning PML into a real tool requires a lot of research and implementation work and this is why we request the help of the ANR. Some of the goals are highlighted in the next sections.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML approach to proofs of specification is unique&#039;&#039;&#039; PML has no dedicated proof language, but the user can still write proofs! Existing programming languages supporting specifications use two alternatives: automated proofs (ACL2, Why) or proof obligations that the user can prove using specific language (Coq extraction, Focalize, Why). Several systems provide both, the manual proofs being used only when automation fails. PML is very different in spirit: it introduces a new instruction, written with a &amp;quot;scissors symbol&amp;quot; &amp;lt;tt&amp;gt;&#039;&#039;&#039;8&amp;lt;&#039;&#039;&#039;&amp;lt;/tt&amp;gt; to express that the corresponding position in the program is &#039;&#039;dead&#039;&#039;, meaning that it can not be reached during evaluation. This condition is checked by a terminating variant of the Knuth-Bendix completion algorithm. This is rather simple and therefore easier to trust than modern decision procedures. However, it only solves trivial cases: to write complex proofs, the user just uses the same syntax as for programs to do case analysis or induction (&#039;&#039;ie.&#039;&#039; recursive definitions). This means that the user does not need learn a specific proof language and hopefully implies that PML is easier to learn and probably more adapted to industry that previous solutions.&lt;br /&gt;
&lt;br /&gt;
The logic of PML is just the equational theory of its programming language; and we use variants of Knuth-Bendix completion as a proof-checker. The first experiments with the current implementation are promising. However, Knuth-Bendix procedure in the context of ML is a complex and new research problem. A lot more work is needed, for instance to handle proofs in arithmetic which occur quite often. Here is an example of a proof in arithmetic, checked in the current version of PML. This is not completely satisfactory (hard to write), but shows the use of the language for both proofs and programs and the use of recursive functions for inductive proofs:&lt;br /&gt;
&lt;br /&gt;
  val rec mul_associative x y z |- (x * y) * z == x * (y * z)&lt;br /&gt;
    proof match x with&lt;br /&gt;
      Z[] -&amp;gt; 8&amp;lt; (* trivial case handled automatically by Knuth-Bendix *)&lt;br /&gt;
    | S[x&#039;] -&amp;gt;&lt;br /&gt;
      let _ = mul_associative x&#039; y z in (* There is a syntactic sugar for that... *)&lt;br /&gt;
        (* this adds the fact that (x&#039;*y) * z == x&#039; * (y*z) to the environment *)&lt;br /&gt;
 &lt;br /&gt;
      let _ = mul_right_distributive y (x&#039; * y) z in&lt;br /&gt;
        (* this adds the fact that (y + x&#039;*y) * z == y*z + (x&#039;*y)*z *)&lt;br /&gt;
 &lt;br /&gt;
        (* the environment now contains enough information for Knuth Bendix to handle the rest:&lt;br /&gt;
         *    - x*(y*z)  ==  y*z + x&#039;*(y*z)  : by definition&lt;br /&gt;
         *    - x*y == y + x&#039;*y : by definition&lt;br /&gt;
         *      and so (x*y)*z == (y + x&#039;*z)*z&lt;br /&gt;
         *    - (x&#039;*y) * z == x&#039; * (y*z)  :  by the recursive call to mul_associative&lt;br /&gt;
         *    - (y + x&#039;*y) * z == y*z + (x&#039;*y)*z : by the call to mul_right_distributive  *)&lt;br /&gt;
      8&amp;lt;&lt;br /&gt;
&lt;br /&gt;
Moreover, this style of proof is declarative and relatively readable (like Mizar proofs) while concise at the same time. This is very important when you want to maintain large developments.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;PML is different from the other modern programming languages&#039;&#039;&#039; because its design focuses on a few powerful concepts. One consequence is that it is more difficult for a compiler to produce efficient code. In particular, since PML unifies several notions of products (modules, tuples and records), there is no simple way to choose the internal representation of a product, especially with implicit subtyping. Writing a good compiler for PML will thus require more complex and original optimization schemes (probably driven by typing) than languages like OCaml or Haskell. A Polish student (Wojciech Matyjewicz) is just starting a PhD on this very topic.&lt;br /&gt;
&lt;br /&gt;
Here is a simple example, accepted by the current version of PML, demonstrating product type, sum type and subtyping. We define ternary trees as an extension of binary trees with an implicit subtyping&lt;br /&gt;
relation (all functions accepting binary_trees will accept ternary trees, by ignoring the &amp;lt;tt&amp;gt;middle_son&amp;lt;/tt&amp;gt;):&lt;br /&gt;
&lt;br /&gt;
 type rec binary_tree (A) =&lt;br /&gt;
   [ Nil[] | Node[A with left_son : binary_tree(A); right_son : binary_tree(A)] ; ]&lt;br /&gt;
 type rec ternary_tree(A) =&lt;br /&gt;
   binary_tree({ A with middle_son : ternary_tree(A) ;})&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML requires a termination criterion&#039;&#039;&#039; because a proof by induction will just be a normal recursive program. Such a program has to be well-founded in order to correspond to a valid proof. A subset of Haskell can now use the Aprove tool to establish termination for simple programs. However, we want the test to be fully integrated with the language, and be compatible with very modular programs. At the moment, these goals seem difficult to achieve with Aprove or other external termination checkers. A first termination criterion based on Lee, Jones &amp;amp; Ben-Amram&#039;s &amp;quot;size-change termination principle&amp;quot; was implemented by Pierre Hyvernat [Hyv10b]. While this test is quite powerful, it is necessarily incomplete, and quite some work is required to make termination proofs of complex programs tractable.&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical description==&lt;br /&gt;
&lt;br /&gt;
===Background, state of the art===&lt;br /&gt;
&lt;br /&gt;
====Programming language====&lt;br /&gt;
&lt;br /&gt;
The ML programming language, created by Robin Milner &amp;lt;em&amp;gt;et al&amp;lt;/em&amp;gt; in the 80&#039;s has two major distinctive features:&lt;br /&gt;
* Algebraic data-types and pattern matching: data types are basically all constructed using fixpoint, cartesian product (product types) and disjoint union (sum types).&lt;br /&gt;
* Static type inference: the type of every piece of code is automatically inferred using Hindley-Milner algorithm (HM). By construction, once compiled, an ML program can not crash (no segmentation fault). More precisely, when we do not use unsafe features of the language (like interface with unsafe libraries written in C), if an ML program produces a segmentation fault, then there is a bug in the type-checker or the compiler.&lt;br /&gt;
&lt;br /&gt;
Recent progress in type inference algorithm uses constraint solving. This means that the type system can be described in first-order predicate logic in such a way that a type inference problem is a formula written in a decidable fragment of first-order predicate logic (often the purely existential fragment). Hence, any constraint solver can be turned into a type-checker for ML. These approach is known as HM(X) (see [SOW97]).&lt;br /&gt;
&lt;br /&gt;
There are two problems with this approach:&lt;br /&gt;
* The complexity of constraint solving can be too high for practical use, especially when using a general purpose constraint solver. To our knowledge, there are currently no mainstream implementation of ML based on HM(X).&lt;br /&gt;
* HM(X) does not completely solve the problem of subtyping. The language to express the types constructed by the constraint solver is the same as the language of types used by programmers. With constraints &amp;lt;math&amp;gt;\alpha \subseteq \beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\alpha \subseteq \gamma&amp;lt;/math&amp;gt; for three types &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\gamma&amp;lt;/math&amp;gt;, the most natural solution is &amp;lt;math&amp;gt;\alpha = \beta \cap \gamma&amp;lt;/math&amp;gt;. This implies that intersection needs to be part of the language for types. This means that constraints such as &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \delta&amp;lt;/math&amp;gt; may also appear and they are problematic to deal with. Similar reasoning shows that constraints of the form &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \beta&#039; \cup \gamma&#039;&amp;lt;/math&amp;gt; may appear, increasing the complexity of constraint solving by an exponential factor.&lt;br /&gt;
&lt;br /&gt;
PML&#039;s approach is to replace type-inference by &#039;&#039;constraint &amp;lt;u&amp;gt;checking&amp;lt;/u&amp;gt;&#039;&#039; rather than constraint solving: we only check that the constraints are satisfiyable in some model. Type-checking in the current implementation of PML can be seen as a black box ensuring that nothing can go wrong during execution. Moreover, since we do not need to write solutions for the constraints, the language for types can be relatively simple. In fact, the types written by the programmer aren&#039;t even the actual type constraints that are checked: they are syntactic sugar for the partial identity on the intended type (giving for free nice feature like higher-order parametric types, that is types with parameters which may be themselves types with parameters). In other words, the expression &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; is a synonym for &amp;lt;tt&amp;gt;(id_nat x)&amp;lt;/tt&amp;gt; where&lt;br /&gt;
  val rec id_nat x = match x with&lt;br /&gt;
      Z[] -&amp;gt; Z[]&lt;br /&gt;
    | S[x&#039;] -&amp;gt; S[id_nat x&#039;]&lt;br /&gt;
is defined internally by PML. The constraints generated by &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; mean exactly that &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is of type &amp;lt;tt&amp;gt;nat&amp;lt;/tt&amp;gt;...&lt;br /&gt;
&lt;br /&gt;
With this approach, we loose type-inference and the ability to display types in error messages. Nevertheless, PML error reporting is quite helpful because, in case of problems, it displays three positions in the code and an error message like this &amp;lt;tt&amp;gt;error at position 1, label &amp;quot;id&amp;quot; projected at position 2 do not appear in the value constructed at position 3&amp;lt;/tt&amp;gt;. This kind of error message is in fact of bounded length and often more useful than OCaml or SML messages. We can understand this as showing three points in the &#039;&#039;slice&#039;&#039; of the error, as introduced by Joe Wells in [HW04].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Proof assistant====&lt;br /&gt;
&lt;br /&gt;
Proof assistants have evolved rapidly since Automath in the 70th. Two main trends coexist: automated proof assistants such as ACL2, PVS and &#039;&#039;safe&#039;&#039; ones such as Coq, Isabelle, PhoX, Lego, HOL, Matita, &amp;lt;em&amp;gt;etc.&amp;lt;/em&amp;gt; The former incorporate very sophisticated automated deduction strategies, with no &#039;&#039;certificate&#039;&#039; for the validity of the proof, while the later require all proofs to be done in a specific framework (like natural deduction or type theory) allowing for a simple check of the proof. The gap between the two approaches tend to be reduced by the emergence of complex tactics (for Coq or Isabelle mainly) which build proofs for the user. For instance Zenon is an advanced automated first-order theorem prover outputing a Coq proof.&lt;br /&gt;
&lt;br /&gt;
The common defect of all these proof assistants is that a proof can not be written nor understood without running the proof assistant. Some proof assistants such as Mizar or Alf do not follow exactly the above scheme: Mizar has a declarative style for proof which is (in theory) readable by a human and checked by a limited checker (This proof style has been adapted to Coq and Isabelle). Unfortunately, there is no formal description of the Mizar proof checker. Alf on the other hand is based on proof theory and requires the user to basically write the complete proof tree just leaving out a few details. The logic is very well formalized and simple, but writing proof is tedious and not similar to the usual practice of informal mathematics.&lt;br /&gt;
&lt;br /&gt;
This picture of the world of proof assistants shows that some fundamental work is needed. In the current version of PML, the logic is just an equational theory of the underlying programming language. This is easily described formally. The proof engine is, like in Mizar, a limited automated checker inspired by the Knuth-Bendix completion algorithm (KB). The completion algorithm used in PML had to be adapted to the higher-order constructs of ML-like languages and restricted to ensure termination and an acceptable complexity. The current limitation is probably too strong: it is limited to closed terms and cannot use universal theorems automatically (as in the first example of section 1, where one has to give explicitly the argument to use distributivity).&lt;br /&gt;
&lt;br /&gt;
Nevertheless, preliminary examples in the current version shows that the approach is worth trying: proofs are concise and readable once you know the language. A very encouraging point is that all examples where written without interface. This really means that proofs are readable without the help of a computer.&lt;br /&gt;
&lt;br /&gt;
===Rationale highlighting the originality and novelty of the proposal===&lt;br /&gt;
&lt;br /&gt;
The final objective of our project would be a full PML compiler, bootstrapped and completely proved with itself (full bootstrap). This does not exist for any language and is far too ambitious for a four years project.  More realistically, we plan to produce a compiler for PML, written in PML, but not proved in PML yet.&lt;br /&gt;
&lt;br /&gt;
We also want to develop proof-checking in such a way as to allow very elegant proofs, supporting the feasibility of a full bootstrap by various examples, some of them being near to industrial application, some others being algorithms coming from implementation of programming languages.&lt;br /&gt;
&lt;br /&gt;
We have focused the existing development on the quality of the language both for proofs and programs. By quality, we mean easy to understand and write (and therefore, easy to learn). We think that using the programming language as a proof language could make formal methods more attractive to the industry without the defect of systems like PVS and ACL2 where the automated tactics replace the need for a proof language, but are sometimes hard to control and use. For instance, finding the right &#039;&#039;lemmas&#039;&#039; to make a proof possible in ACL2 is quite difficult.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other proof systems devoted to programming.&#039;&#039;&#039; Many other proof systems have been used or specifically developed&lt;br /&gt;
to allow the production of certified code: extraction in Coq, Why with its automated prover Who from the Proval project, Focalize, PVS, ATS, ... None of these system uses the programming language as a proof language. They all have a dedicated language for proofs and even if some of them like Focalize or Coq extraction using a Mizar style mode for proof, have readable proofs, learning the proof language is never trivial. Other systems like PVS, ATS, Why using Who rely on automated deduction. In those cases, the behavior of the automated prover is always hard to predict.&lt;br /&gt;
&lt;br /&gt;
Another selling point is that the logic and programming language are fully integrated. This is not a two level systems like most systems (but not all, ACL2 for instance is fully integrated). In PML, the statements of theorems and their proofs are expressions at the same level than programs. This means that a program can contain specifications that contains themselves program definitions in their statement or proof and so on. This is generally not possible (even in ACL2) and makes it possible to write modules with their specifications.&lt;br /&gt;
&lt;br /&gt;
One of the key idea for this project is that any ML-like programming language has all the features needed for a proof language: case analysis via pattern matching and exception handling, induction, calling previously defined program/theorems. This means that it is natural to explore this direction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other programming languages&#039;&#039;&#039;. Another key idea in PML is to develop the language and its proof-checker together. This has a great impact on the design of PML. Let&#039;s illustrate this with a concrete example: exception handling. In ML, there is a construct&lt;br /&gt;
  try P with e -&amp;gt; R&lt;br /&gt;
but, this is not sufficient to do case analysis on the fact that a program &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises or not an exception. In particular, &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; can be the proof just in case &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises an exception. However there is no place holder for the normal case (without exception). This is why we had to introduce a&lt;br /&gt;
  let try x = P in Q with e -&amp;gt; R&lt;br /&gt;
where &amp;lt;tt&amp;gt;Q&amp;lt;/tt&amp;gt; is evaluated only when &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; reduces to a value.&lt;br /&gt;
&lt;br /&gt;
A great number of decisions on the language design comes from the interaction between the development of the programming language and its proof-checker. Another key feature of PML, which makes the project original even as a programming language compared to many other projects of programming language research (GALLIUM, Haskell, Scala, ...) is the use of constraint checking. This choice arises from the fact that we want a language as small as possible, because a proof-checker is complex and therefore, we want to fully unify all sorts of Cartesian product including modules, records, tuples and variant with multiple argument. This is already achieved in the current implementation of PML and to my knowledge, no ML like language have a unique but still powerful notion of Cartesian product.&lt;br /&gt;
&lt;br /&gt;
All the systems previously mentioned allow to prove programs in limited subsets of existing languages like ML or Haskell. The prover has to find ways to deal with those languages&#039; defects rather than improve them...&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical program, project management==&lt;br /&gt;
&lt;br /&gt;
===Specific aims of the proposal===&lt;br /&gt;
&lt;br /&gt;
As said in the previous section, the final objective would be to have a fully bootstrapped PML language: this would mean that PML is entirely written and proved in PML. This would be too ambitious at first, and we chose to focus here on the design of the language plus a proof of concept, that is compilation and proof of various examples, searching to do our best on the following points:&lt;br /&gt;
&lt;br /&gt;
* Natural way of writing programs (Task 1)&lt;br /&gt;
* Efficiency of the code generated by the compiler, despite the heavily use of subtyping (Task 3)&lt;br /&gt;
* Readable and short proofs (Task 1, Task 4)&lt;br /&gt;
* Efficiency of type-checking and compilation (Task 2 and 6)&lt;br /&gt;
* Efficiency of proof-checking (Task 4 and 6)&lt;br /&gt;
* All of the above points need testing, and we created a transverse fifth task for that.&lt;br /&gt;
&lt;br /&gt;
===Project management===&lt;br /&gt;
&lt;br /&gt;
We plan to have one 3 days workshop per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems. We already have the agreement of some people to participate in such meetings: Joe Wells, Assia Mahbouby, Andreas Abel, ...&lt;br /&gt;
We plan to have one 3 days meetings per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems.&lt;br /&gt;
&lt;br /&gt;
We will also organize two project meetings per year, just to keep track of progress, share idea and organize the above workshops and other invitations.&lt;br /&gt;
&lt;br /&gt;
We want also to organize visits of one or two members of the project to visit researchers on similar topic (typically a member of the project could visit one of the invited speaker of our workshop). Members of the project should also travel to conference on the subject like POPL, LICS, CSL, TYPES or the recently created CPP (first conference in 2011).&lt;br /&gt;
&lt;br /&gt;
===Detailed description of the work organized by tasks===&lt;br /&gt;
&lt;br /&gt;
====Task 1 - theoretical work, design of the language ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Alexandre Miquel, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.a - Correctness of the constraint checking algorithm&#039;&#039;&#039; (delivered&lt;br /&gt;
09/2012): [RAF10b] already cover the correctness without polymorphism. A draft version of &lt;br /&gt;
the correctness proof with polymorphism does exist but needs more work. The &lt;br /&gt;
main open problem here is the interaction with the termination-check. The current work &lt;br /&gt;
proves that when constraints are checked, the program can only loop via recursive definitions.&lt;br /&gt;
Then, we would like to prove that the program is terminating if recursive definitions are accepted by the &lt;br /&gt;
termination checker. However, this is non trivial.&lt;br /&gt;
&lt;br /&gt;
This being a central piece of PML, it should be also one&lt;br /&gt;
of the first tests for PML in task 5. We could also prove this part of PML in&lt;br /&gt;
Coq (in fact 2 provers proving themselves and each other correct is a much&lt;br /&gt;
stronger warranty than one prover proving itself).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.b - Consistency of proof-checking&#039;&#039;&#039; (beginning 09/2011, delivered before 09/2013 for the core of the language): This is essential for clearly defining the logic of PML and prove its consistency. This should not be too hard for the core of the language. However, this proof has to be extended to take into account all future extensions of the language and could be seen as a &#039;&#039;permanent task&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.c - Adaptation of uniqueness typing to the context of constraint checking&#039;&#039;&#039; (beginning 09/2012, delivered 01/2014): The current version of PML is a pure functional programming language, with no imperative feature. This is problematic, because input/output is necessary for real programs and affectations are required for efficiency especially when using large arrays. We plan to adapt the approach of the [http://clean.cs.ru.nl/ Clean language] [AGR92], [AcP95], [AcP97], [VPA07]. In Clean, all programs can be analyzed as purely functional programs, but the type system can check that some data are not used any more and reuse the place in memory for other data (allowing affectation). For instance, in such a context writing in a file &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; can be written as &amp;lt;tt&amp;gt;let f&#039; = write f str in ...&amp;lt;/tt&amp;gt;, but the compiler must check that &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; will not be used anymore implying the equivalence between the standard imperative semantics of writing to file and the purely functional semantics used by proofs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.d - Private, abstract and existential types.&#039;&#039;&#039; (beginning 09/2011, delivered&lt;br /&gt;
09/2012 for private type, beginning 09/2012, delivered&lt;br /&gt;
09/2013 for existential types and beginning 09/2013, delivered 09/2015 for abstract&lt;br /&gt;
types)&lt;br /&gt;
 &lt;br /&gt;
Abstract data types hide the definition of a data type and allow the user of&lt;br /&gt;
a library to be sure that his code will continue to work even if the internal&lt;br /&gt;
representation of data are changed. In the context of constraint-checking in&lt;br /&gt;
PML, adding abstract data types seems to be a challenging task. Moreover,&lt;br /&gt;
abstract data-types are a form of existential quantification over types and&lt;br /&gt;
could raise some consistency issues. We hope to find a way to incorporate&lt;br /&gt;
abstract types in PML without loosing coherence.&lt;br /&gt;
 &lt;br /&gt;
A first step would be private data types. They are a very simple yet very powerful mechanism for easily&lt;br /&gt;
ensuring invariants on all values of a data type. This mechanism is as&lt;br /&gt;
follows: the compiler simply checks that the constructors of a data type are&lt;br /&gt;
not used for constructing values. Values are constructed by using construction&lt;br /&gt;
functions, like with abstract data types. However, unlike with abstract data&lt;br /&gt;
types, constructors can still be used as patterns for defining functions by&lt;br /&gt;
pattern-matching. Hence, a library on a private data type is not closed but&lt;br /&gt;
can be extended easily. Private data types are therefore an important and very&lt;br /&gt;
useful feature for defining data structures with complex invariants and&lt;br /&gt;
proving their correctness more easily. They have been implemented in OCaml by&lt;br /&gt;
Pierre Weis and are described in Frédéric Blanqui, Thérèse Hardin and Pierre&lt;br /&gt;
Weis&#039; ESOP&#039;07 paper [BHW07].&lt;br /&gt;
&lt;br /&gt;
A second step would be existential types, which are very similar to abstract types,&lt;br /&gt;
but with no free name for the abstract type. On a logical level, they do imply an existential quantification over types&lt;br /&gt;
which has to be limited to ensure consistency. However existential types do not require the type to have a free name, which corresponds in logic to a definite description operator (similar to Hilbert&#039;s epsilon operator), and this, being connected to the axiom of choice (over types), may be really problematic for consistency. Some work related to this exists in the phd thesis of F. Ruyer, a former student of C. Raffalli [Ruy06].&lt;br /&gt;
&lt;br /&gt;
====Task 2 - termination====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Pierre Hyvernat&lt;br /&gt;
&lt;br /&gt;
Participants: Christophe Raffalli, Andreas Abel, Frederic Blanqui&lt;br /&gt;
&lt;br /&gt;
Remark: this is an essential task, running during the 4 years. There will always be some embarrassing examples that do not work, but could work... both for the core and auxiliary criterion (see below for the distinction) meaning that this research field will remain open forever.&lt;br /&gt;
&lt;br /&gt;
Even if it might be counter-intuitive at first, it is often necessary to write programs whose execution can be infinite. For example, any kind of &amp;quot;server&amp;quot;, or almost any interactive program might have infinite executions. Even in purely mathematical setting, it can be interesting to have intermediary non-terminating functions. Consider a function outputting the stream of prime numbers : even if this function is non-terminating, we might use it in a terminating manner in a proof by requesting the &#039;&#039;n&#039;&#039; first prime numbers.&lt;br /&gt;
&lt;br /&gt;
Since PML uses full recursion (keyword &amp;lt;tt&amp;gt;rec&amp;lt;/tt&amp;gt;), writing such programs is easy. On the other hand, the notion of &amp;quot;terminating&amp;quot;, or &amp;quot;well-founded&amp;quot; recursive function isn&#039;t part of the core of PML: such programs are just special cases of recursive programs. The user will have to specify which functions are in fact terminating and might have to prove it himself when PML cannot infer termination automatically.&lt;br /&gt;
&lt;br /&gt;
Proofs of specifications are just PML programs, and those cannot be allowed to run infinitely. More precisely, even if proof will never be run at all (no computational content), they are required to be well-founded. The consistency of PML relies on this. In order to relieve the user from proving that all proofs are in fact terminating, PML should offer a way to check automatically that (some) functions are terminating. Because the halting problem is undecidable, it is hopeless to do that in all generality, but this is seldom necessary: many proofs terminate for obvious reasons. PML should only work for most of the functions, most of the time (rather than work for all the functions, all the time...)&lt;br /&gt;
&lt;br /&gt;
Technically speaking, PML can infer an error called &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; when it encounters a program which, it thinks, may not terminate. Such an error cannot be captured: this is an error rather than an exception. The property we need to guarantee is that if PML doesn&#039;t infer the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; possible, then the program in question does indeed terminate. If the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; is possible for a terminating function, the user can still provide PML with a proof that this error is never raised. PML current syntax for that is &amp;lt;tt&amp;gt;[p proof ... ]&amp;lt;/tt&amp;gt; where &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; is a term and &amp;lt;tt&amp;gt;...&amp;lt;/tt&amp;gt; is a proof that &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; doesn&#039;t raise any exception nor error (this is the desired property for proofs).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.a - Core termination criterion&#039;&#039;&#039; (delivered 09/2010)&lt;br /&gt;
&lt;br /&gt;
This first test is now part of PML. Since primitive recursive function isn&#039;t enough in practice, even for proofs, a subtler and more powerfull termination criterion has been implemented. This is an extension of the &amp;quot;size change principle&amp;quot; of Lee, Jones and Ben-Amram [LJ01]. This test successfully checks termination for primitive recursion, lexicographic ordering and permutation of arguments and thus covers most simple practical cases. The implementation is quite similar to the original size-change principle, but the proof of correctness is surprisingly more difficult: see [Hyv10b].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.b - Improvement of the core termination criterion&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
The size-change principle is simple and powerful, but many cases occurring in practice aren&#039;t tagged as terminating. We plan to adapt to PML a termination criterion based on the technique of type-based termination, which allow for recursive calls through size preserving functions such as &amp;lt;tt&amp;gt;List.map&amp;lt;/tt&amp;gt;. There are several possibilities, ranging from simple systems such as the one developed by Abel (RAIRO&#039;04) [Abel04], Barthe et al (MSCS&#039;04) [Bar04] or Blanqui (RTA&#039;04, CSL&#039;05) [Bla04, Bla05c], to the very rich system of Blanqui and Riba (LPAR&#039;06) [BlR06]. In the latter, given for each function some formula in Presburger arithmetic describing how the size of the output is related to the size of the inputs (the correctness of which can be checked automatically), the termination follows from the fact that recursive calls are done on strictly decreasing arguments, using for instance lexicographic or multiset comparisons together with linear combinations of the arguments. Intermediate systems, such as the one of Barthe, Grégoire and Riba (CSL&#039;08) [BGR08] which is powerful but with a lower complexity than Presburger arithmetic, have also to be considered.&lt;br /&gt;
&lt;br /&gt;
This development looks rather orthogonal to the implemented criterion and might require small modification of other parts of PML in order to get the appropriate information. On a different level, slight extensions should be added to the existing criterion to enhance its complexity on some specific examples that are recognized as termination, but not in a reasonable time.&lt;br /&gt;
&lt;br /&gt;
This core termination needs to reach an acceptable compromise between power and simplicity. In particular, the most complex developments may not find their way into the core termination criteria, but rather be used in the next task...&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.c - Use of external provers&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
In order to circumvent the limitations of the core termination criterion, we propose to use external powerful termination provers like [http://aprove.informatik.rwth-aachen.de/ Aprove] or [http://colo6-c703.uibk.ac.at/ttt2/ TTT2] that implement and combine many other termination techniques. To this end, we can define translations from PML programs to one or more of the possible formats currently used in the [http://termination-portal.org/wiki/Termination_Competition annual international competition on termination] and in particular: first-order rewrite systems (TRS), dependency pair problems (DP problem), higher-order rewrite systems (HOTRS) or Haskell programs. In particular, we could reuse some of the techniques used for converting Haskell programs into first-order DP problems in [Gie06].&lt;br /&gt;
&lt;br /&gt;
But to which extent can we trust the results of these provers? Hopefully, now, many termination provers provide certificates in a format called [http://cl-informatik.uibk.ac.at/software/cpf/ CPF] that can be checked by certified, dedicated tools like [http://cl-informatik.uibk.ac.at/software/ceta/ CeTA], [http://color.inria.fr/ Rainbow] or [http://a3pat.ensiie.fr/ CiME3].&lt;br /&gt;
&lt;br /&gt;
The most pragmatic route is simply to trust those tools and concentrate on proving that the translation from (restricted) PML code to the input language is indeed correct. Of course, the ideal solution would be to be able to translate the external certificates into an equivalent PML program whose termination can be infered by the core criterion. The complexity of tools like [http://aprove.informatik.rwth-aachen.de/ Aprove] makes it look very difficult and it is probably hopeless to do that in a general manner.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.d - Modularity and termination&#039;&#039;&#039; (beginning 09/2013, never ending)&lt;br /&gt;
&lt;br /&gt;
The core termination prover does not use the definition of functions to prove their termination, but only information gathered from the typing constraints. When using external prover, for large development, one also would like to avoid sending a large piece of code to the external prover. &lt;br /&gt;
&lt;br /&gt;
Function such as &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; preserves the length of list. But the notion of length does not appear explcitely in the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. This means that the current core termination prover often can not prove termination of a function that use &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. It also means that you need to give the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; to an external tool. &lt;br /&gt;
&lt;br /&gt;
We would like to automatically compute some concise information about the size differences between input and output of program. This means that we would like to infer (when possible) a notion of &#039;&#039;size&#039;&#039; from the definition of a function.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Remark&#039;&#039;&#039;: The halting problem is undecidable, the available external tools for checking termination are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the termination checker.&lt;br /&gt;
&lt;br /&gt;
====Task 3 - compilation ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Wojciech Matyjewicz, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.a - A first compiler using LLVM&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012) LLVM is a compiler infrastructure providing many tools: compilation strategy, virtual instruction set, compiler infrastructure, tools to write high level virtual machines, etc. LLVM is very attractive, because it is rather simple to use (it even has an OCaml interface) and can compile for a bytecode interpreter, can be used as a JIT compiler or a standard compiler. Moreover, it support a lot of platforms. It also provide some optimizations, which is important. We think that writing a compiler, with no optimization, for PML using LLVM should not be too hard (this is important that this task be easy, because this is not really research ...)&lt;br /&gt;
&lt;br /&gt;
A polish phd student Wojciech Matyjewicz has started to work on this in december. He visited the LAMA during one week to start the project. It is important to note that he is a first year phd in Poland and the first year there is equivalent to our Master 2. Which means that Wojciech Matyjewicz is a potential candidate.&lt;br /&gt;
&lt;br /&gt;
Then, we would like to improve our compiler in various direction. We mention here the ones that are innovative in this domain (we should also consider more standard optimization, but we do not mention them specifically). &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.b - Representation of cartesian product and disjoint sum&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012 for product) PML allows only one kind of cartesian product which in general (because of multiple inheritance and implicit subtyping) must be represented as a table (hash-table or maps based on binary search trees). These can impact performance. We plan to generate extra constraints for each occurrence of a constructor of a cartesian product in a program. Then, solving this constraint in a way that maximize speed (or size) should allow for a representation of cartesian product that is more efficient than using, for instance, OCaml. The same kind of optimization (with a different optimization criterion) should be done for sum types and the implementation of pattern matching. This optimisation should be included in the first compiler because the implentation with tables is too costly for a temporary solution.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.c - Unboxing&#039;&#039;&#039; (depends on some parts of 3.b, beginning 1/2012, delivered 1/2013) In general, 32 bits integer and floating point number are boxed (that is represented by a pointer). This allows a more elegant language. This can lead to major impact on performance especially when arrays are involved. We think that constraint-checking is a good framework to propagate type information and allow efficient unboxing. Nevertheless, doing enough unboxing to try to match the performance of low level languages like C is very hard. We hope that we can reuse some of the work of task 3.b, because unboxing can be seen also as the optimization of the representation of a cartesian product with only one field.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.d - compilation of affectation (reference and arrays) and IO&#039;&#039;&#039; (depend upon 1.c, beginning 09/2012, delivered 03/2014) After adapting uniqueness typing to PML (task 1.c), we will be able to compile affectation and IO imperatively as in any imperative programming language.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.e - Garbage collection&#039;&#039;&#039; (beginning 01/2014, delivered 09/2014) For simplicity reasons, the first compiler will simply use Boehm&#039;s garbage collector. This garbage collector is relatively efficient and simple to use. However, Boehm&#039;s GC isn&#039;t optimised for the kind of allocations used in a functional language. Moreover, having a multithreaded GC could prove usefull in moder environment. We thus plan to replace Boehm&#039;s GC by a dedicated GC tuned for our purposes.&lt;br /&gt;
&lt;br /&gt;
Writing a GC that is both efficient and correct is not easy, and this sub-task is rather orthogonal to the PML language, which explains why it only comes later during the project. Nevertheless, we feel it is necessary to go through the trouble if we want to be as efficient (or even better, more efficient) than existing functional languages...&lt;br /&gt;
&lt;br /&gt;
====Task 4 - Automated reasoning====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Frédéric Blanqui&lt;br /&gt;
&lt;br /&gt;
Participants: Frédéric Blanqui, Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
The kernel of the proof engine will be based on completion techniques. Knuth-Bendix completion tries to transform a set of unoriented equations into a set of (inter-reduced and) convergent, that is, terminating and confluent, set of rewrite rules. It can therefore be used for proving that some equality is the equational consequence of some equational theory. Indeed, when an equational theory can be completed into a convergent rewrite system, two terms are equivalent in this equational theory if their normal form in the convergent rewrite systems are equal.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.a - Adaptation of the Knuth-Bendix completion algorithm to PML&#039;&#039;&#039; (already started, delivered 09/2015) As explained just before, Knuth-Bendix completion is based on rewriting. However, in PML, programs are not rewriting systems. We therefore need to adapt Knuth-Bendix completion. We need both generalization, to use the notion of constructor present in ML and take care of the higher-order nature of ML (even if we can not hope much here).&lt;br /&gt;
As said above, something is already implemented, but it is trivial because completely restricted to closed terms. A first version should be able at least to rewrite a closed term modulo some simple equational (and universal) theory. An important point here is to ensure termination&lt;br /&gt;
of this algorithm and even a low complexity. The price to pay, will be incompleteness. A lot of care should also be devoted to the correctness of the implementation, because like for task 3.a, the consistency of PML relies on it.&lt;br /&gt;
&lt;br /&gt;
This task in one of the major task for PML and a first version already exists, but is non terminating in presence of equalities between functions: if we have an equation like &#039;&#039;f = f o f&#039;&#039;, PML may use this equation has a definition of &#039;&#039;f&#039;&#039; and loop. For dealing with these cases, we are considering a fix which involves some notions similar to those of &#039;&#039;geometry of interaction&#039;&#039;. Another particular and very important case of universal equation that we should take into account is associativity and commutativity. It is indeed very important to ease proofs on integers (addition and multiplication are associative and commutative). To this end, we could reuse the [http://cime.lri.fr CiME] library.&lt;br /&gt;
&lt;br /&gt;
Note that this work could benefit to other projects and tools, like [http://moca.inria.fr/ Moca], a generator of construction functions for private data types with algebraic invariants, also based on completion, or Europa, a proof assistant based on the lambda-pi-calculus modulo rewriting developed by Gilles Dowek and [http://www.lix.polytechnique.fr/Labo/Mathieu.Boespflug/ Mathieu Boespflug]. Indeed, currently, Moca generates OCaml code without guarantee on its correctness. Using PML instead, Moca could also generate a proof of the correctness of the generated construction functions.&lt;br /&gt;
Then, later, when trying to prove the correctness of a function defined on this private date type, one can use the invariants satisfied by the values of the private data type as assumptions, since these invariants are satisfied by construction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.b - Use of external provers&#039;&#039;&#039; (beginning 03/2012, delivered 09/2015) Like for termination proofs, in order to increase the proving capacities of PML, we will provide a translation of PML proof goals into the [http://www.cs.miami.edu/~tptp/ TPTP standard format] of the CASC competition in order to be able to use external provers too, and in particular provers based on completion like [http://www.waldmeister.org/ Waldmeister], [http://cime.lri.fr/ CiME] or [http://cl-informatik.uibk.ac.at/mkbtt/ mkbTT] but not only. And possibly some certifying provers like [http://focal.inria.fr/zenon/ Zenon] based on tableaux or [http://alt-ergo.lri.fr/ Alter-Ego] based on SMT (SAT solver modulo theory).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Same remark than for termination&#039;&#039;&#039;: The problem is undecidable, the available external tools for automated reasonning are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the automated reasonning.&lt;br /&gt;
&lt;br /&gt;
====Task 5 - validation (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Christophe Mouilleron, Tom Hirschowitz.&lt;br /&gt;
&lt;br /&gt;
The validation requires to write numerous examples to check that we fulfill our main goal, which is that all programs (with or without proof) are written in the best possible way. This work being research, we think that it is important that any piece of code written in PML that does not look &#039;&#039;right&#039;&#039; is carefully examined to check that this is not due to a defect in language design.&lt;br /&gt;
&lt;br /&gt;
Christophe Mouilleron and Erik Martin-Dorel started to work on the axiomatisation of computer arithmetics within an ongoing PEPS project. This is a good test for PML and moreover a requirement &lt;br /&gt;
because we want PML to be a real programming language and thefore the limited arithmetic of processors (32 and 64 bits integer and floating point number) must be supported by PML. However, proving software using them is not trivial at all and Christophe Mouilleron member of the Arénaire team in ENS Lyon is a specialist in this domain.&lt;br /&gt;
&lt;br /&gt;
Tom Hirschowitz and Christophe Raffalli already started (and almost finished) a proof in PML that &lt;br /&gt;
categories, functors and natural transformations form a 2-category (this development is available in the example directory in the current version of PML). We plan to continue such abstract developments and we think that they could lead to interesting perspectives about the modularity of PML.&lt;br /&gt;
&lt;br /&gt;
More general code, including a standard library and some significant mathematics should be developed (there is already around 10.000 lines of PML code in the current distribution). Moreover, we started to port Pierce et al.&#039;s course, in Coq, on software foundations (http://www.cis.upenn.edu/~bcpierce/sf/), to PML. The first three files are translated and there remain a dozen of files of around 2500 lines to translate. This is a major work, but would provide a very good test for PML, and a good tutorial.&lt;br /&gt;
&lt;br /&gt;
This task should deliver at least 100.000 lines of PML code to have&lt;br /&gt;
a sufficient corpus to say in which respect we fulfilled our goals.&lt;br /&gt;
&lt;br /&gt;
==== Task 6 - Optimisation of PML (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: C. Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: All (anyone could optimize the part of PML he was involved in).&lt;br /&gt;
&lt;br /&gt;
Some of the choice in the design of PML involve rather complex algorithm. Notably, this is the case of the constraint checking algorithm and completion procedure. The first implementation is not trivial but not optimized either. And very often, we have discoverd and will continue to discover that PML is too slow. This goal of this trasversal task is to ensure that PML is usable. &lt;br /&gt;
&lt;br /&gt;
Currently, some optimisations were already added. For instance, PML uses a sat solver for various &lt;br /&gt;
tasks: completeness and usefulness of cases in pattern matching and dealing with negative &lt;br /&gt;
hypothesis (like &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is not equal to &amp;lt;tt&amp;gt;S[x]&amp;lt;/tt&amp;gt;) in the completion procedure. Improving the sat solver using J.C. Filliâtre work [] and simploifying the formula before giving them to the sat solver were a major improvement.&lt;br /&gt;
&lt;br /&gt;
A lot of other optimisations are planned: &lt;br /&gt;
* The graph used to encode the typing constraints should probably be reduced (that is we should compute its transitive reduction). &lt;br /&gt;
* The completion procedure stores a set of terms of the language and we need a fast way to recover the set of all term using a given sub-term. The current implementation is too naïve. &lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
=== Planning of tasks, deliverables and milestones ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The following diagram represents the summary of the tasks and subtasks, together with the intended planning:&lt;br /&gt;
&lt;br /&gt;
[[Image:pml-gantt.png]]&lt;br /&gt;
&lt;br /&gt;
==Data management, data sharing, intellectual property and results exploitation==&lt;br /&gt;
&lt;br /&gt;
Results in each of the tasks will be published in journals (APAL, TCS, ...) and international conferences as usual (LICS, TLCA, CSL, CIE, ...).&lt;br /&gt;
&lt;br /&gt;
PML language is already distributed as open source software under the Cecill-B license. We think that for such a research platform, this is the only possible way to ensure that people will try it. As soon as a first compiler is available, we plan to produce easy-to-install packages, at least for some well-known Linux distributions (Debian and its derivatives seem a good choice).&lt;br /&gt;
&lt;br /&gt;
==Consortium organization and description==&lt;br /&gt;
&lt;br /&gt;
===Relevance of the partner for the project===&lt;br /&gt;
&lt;br /&gt;
This project involve only one partner, the LAMA (UMR 5127), where the coordinator of the project already developed the proof assistant PhoX. The main characteristic of PhoX is to be rather simple to use due to a set of tactics which is limited (less than 20 for the principal ones), but powerful. Moreover, tactics are extensible by &#039;&#039;incorporating theorems&#039;&#039; inside the tactics.&lt;br /&gt;
&lt;br /&gt;
Clearly, this means that efficiency was the main goal of PhoX. Unfortunately, like all tactical theorem prover, PhoX proofs are not readable. After a few attempts with a Mizar-like mode for PhoX, Christophe Raffalli decided to move to a new theorem prover, starting from scratch.&lt;br /&gt;
&lt;br /&gt;
Pierre Hyvernat is also in Chambery and the second developer of PML (he wrote the current termination checker). Tom Hirshowitz has some prior experience in his phd about the compilation of functional languages. At ENS Lyon, which is very near to Chambéry, Alexandre Miquel is a specialist of consistency proof for logical framework. Therefore, Chambery is the very natural partner for this project.&lt;br /&gt;
&lt;br /&gt;
===Qualification of the project coordinator and members===&lt;br /&gt;
&lt;br /&gt;
The coordinator and various members of the project comes from various horizon (see section 7), but they have a common background around the use and development of programming language and/or formal methods. We think that this variety, the small number of members, should allow for good communication and should be very fruitful. &lt;br /&gt;
&lt;br /&gt;
We think, that compared with the development of PML by Christophe Raffalli alone, such a team should speed up the development of PML approximately by a factor 3, making it possible to deliver a very innovative and useful tool at the end of the project. The lack of support for such a team would certainly limit the tool to an experimental toy with many development only partially (or even not at all) integrated in the project.&lt;br /&gt;
&lt;br /&gt;
Christophe Raffalli will also ask for delegations during the project to be able to spend even more time on it.&lt;br /&gt;
&lt;br /&gt;
==Scientific justification of requested budget==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Meetings (total 9720€ per year)====&lt;br /&gt;
 &lt;br /&gt;
Two meetings and one workshop per year, 3 days each, for 7 people. Each meeting costs&lt;br /&gt;
1 train ticket in France, 3 days and 2 nights:&lt;br /&gt;
3*7*(100 + 3*20 + 2*80) = 6720€. &lt;br /&gt;
&lt;br /&gt;
For the workshop, we have to invite 2 to 3 guests. Some may come from foreign country and we estimate the cost&lt;br /&gt;
to 3000€ per year. Which mean a total of 9720€ per year.&lt;br /&gt;
&lt;br /&gt;
====Visits (total 10000€)====&lt;br /&gt;
&lt;br /&gt;
We think that this is very important for this project to interact with other project.&lt;br /&gt;
For instance, Andreas Abel came to visit Chambéry in 2010 for two weeks financed by our PEPS&lt;br /&gt;
project and during this time induced an important bootstrap to the implementation of the termination checker &lt;br /&gt;
[Hyv10b] and contributed a non trivial example with a proved implentation of left-leaning red-black trees.&lt;br /&gt;
&lt;br /&gt;
We want to continue such interaction. Andreas Abel already agreed as well as Joe Wells for discusion about error reporting and , Assia Mahboubi for complex proofs involving the reflexion principle. Many other discussion would be profitable about PML runtime (with multithreading ?), interaction with external tools (termination checker or automated theorem prover), &lt;br /&gt;
uniqueness typing (meeting with people already using such technics), ...&lt;br /&gt;
&lt;br /&gt;
We plan around 4 short visits of one or two weeks from people outside the project to Chambéry and the same amount for short visit in the other direction. This means around 12 weeks per year with 8 travels for a cost of 500€ per week (x12) plus in average (depending if we use plane or train) the same amount for each travel (x8), with a total of 10000€ per year.&lt;br /&gt;
&lt;br /&gt;
====Conferences (total 9600€ per year)====&lt;br /&gt;
 &lt;br /&gt;
The members of the ANR will submit papers to international conferences and&lt;br /&gt;
journals and attend to specialized workshop. We have 2.5 person/year on the project with means &lt;br /&gt;
around 3 international conferences or workshop per year (estimated cost 2000€) and one national conference or workshop per year (estimated cost 1200€)&lt;br /&gt;
&lt;br /&gt;
====Master internships (total 1500€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We plan to host around four master internships in good conditions (possibly&lt;br /&gt;
followed by PhD studentships not financed by the ANR): one per year with a total cost of&lt;br /&gt;
6000€ (1500€ each: 300€ for travel and 200€ per month for an accommodation at&lt;br /&gt;
the CROUS).&lt;br /&gt;
&lt;br /&gt;
====Computers (total 2000€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We consider that the ANR project has to participate in the renewal of the&lt;br /&gt;
computers of its participants. The lifetime of a computer being 4 years and&lt;br /&gt;
the total number of month for permanent members of the project being 112, we&lt;br /&gt;
think that we should pay for 4 computers with an average value of 2000€ each&lt;br /&gt;
(we need powerful computers and laptops, because automated reasoning requires&lt;br /&gt;
a lot of computations and memory).&lt;br /&gt;
&lt;br /&gt;
====Human resources financed by the ANR (1 PhD student, 2 two years postdocs and 4 month of invited professor)====&lt;br /&gt;
 &lt;br /&gt;
This project involves many tasks and 7 members. However, all members&lt;br /&gt;
apart from the coordinator and Pierre Hyvernat can only devote 2-3 month per year to this project&lt;br /&gt;
(they are involved in other ongoing research). Although this is far from&lt;br /&gt;
negligible, we think that we will need more human power: we estimate that 1&lt;br /&gt;
PhD and 2 postdocs are reasonable. &lt;br /&gt;
&lt;br /&gt;
We also consider that one year post-doc are not sufficient, because the time need to &lt;br /&gt;
understand the existing code base is long and the student has both to write code and &lt;br /&gt;
publish its result. Moreover, the code produced by the student will not be an experimental&lt;br /&gt;
code to support its publication, but code which should remain in the project and be maintened by &lt;br /&gt;
other member of the project. In one year, this seems impossible to achieve.&lt;br /&gt;
&lt;br /&gt;
Moreover, as mentioned in the section about visits, we would like to have 1 month per year of invited professor.&lt;br /&gt;
&lt;br /&gt;
This would give a total 88 months (4 month invited, 36 for the PhD and 48 for the 2 postdocs)&lt;br /&gt;
To be compared with the total of 104/112 month not payed by the ANR. We consider that this is a good balance.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 308589€.&lt;br /&gt;
&lt;br /&gt;
====Human resources not financed by the ANR====&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! month/year&lt;br /&gt;
! percentage&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Raffalli&lt;br /&gt;
| 10&lt;br /&gt;
| 85%&lt;br /&gt;
|-&lt;br /&gt;
| Frédéric Blanqui&lt;br /&gt;
| 4&lt;br /&gt;
| 25%&lt;br /&gt;
|-&lt;br /&gt;
| Emmanuel Chailloux&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Tom Hirshowitz&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Pierre Hyvernat&lt;br /&gt;
| 6&lt;br /&gt;
| 50%&lt;br /&gt;
|-&lt;br /&gt;
| Alexandre Miquel&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Mouilleron&lt;br /&gt;
| 0/2&lt;br /&gt;
| 0/15%&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total per year&#039;&#039;&#039;&lt;br /&gt;
| 26/28&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total for 4 year&#039;&#039;&#039;&lt;br /&gt;
| 104/112&lt;br /&gt;
| &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Remark: the situation of Christophe Mouilleron is unknown next year. If it is possible he will &lt;br /&gt;
continue is work on PML started with the PEPS for around 2 month per year. But if it is not possible, &lt;br /&gt;
or if he is selected for the post-doc position, then we should not count it. We used the worst case&lt;br /&gt;
on the website.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 350333€ snas ternir compte de Christophe Mouilleron.&lt;br /&gt;
&lt;br /&gt;
==Annexes==&lt;br /&gt;
&lt;br /&gt;
===CV, Resume of all project members===&lt;br /&gt;
&lt;br /&gt;
==== Christophe Raffalli (project coordinator) ====&lt;br /&gt;
&lt;br /&gt;
Age 41, MCF at the LAMA (UMR 5127) since September 1997.&lt;br /&gt;
&lt;br /&gt;
After his PhD in Paris VII (defended in February 1994), Christophe Raffalli spent 1 and a half year at the LFCS in Edinburgh, 2 years at Chalmers university in Göteborg (post-doc of the TYPES European project) and 1 year as ATER in Créteil University.&lt;br /&gt;
&lt;br /&gt;
Research administration: For ten years, the LAMA was sub-site of the Paris VII site inside the TYPES project which was renewed several times and Christophe Raffalli was the coordinator for this sub-site. Currently the project is not financed by the E.U. Nevertheless, Christophe Raffalli is in charge of the organization of the next TYPES meeting in Aussois in May 2009.&lt;br /&gt;
&lt;br /&gt;
His research interests include:&lt;br /&gt;
&lt;br /&gt;
* theory and implementation of proof assistants,&lt;br /&gt;
* proof theory,&lt;br /&gt;
* implementation of programming languages (especially type-systems).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Raf10b] &#039;&#039;Realizability for programming languages&#039;&#039; (submitted, available as hal-00474043)&lt;br /&gt;
&lt;br /&gt;
* [Raf08a] &#039;&#039;PML and strong normalisation&#039;&#039; conference at the Types workshop, April 2008, Turino, Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf07b] &#039;&#039;PML: a new proof assistant&#039;&#039; conference at the Types workshop, may 2007, Cividale del Friuli (Udine), Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf06a] &#039;&#039;Realizability of the axiom of choice in HOL (An analysis of Krivines&#039;s work)&#039;&#039; with Frédéric Ruyer in Fundamenta Informaticae (2006)&lt;br /&gt;
&lt;br /&gt;
* [Raf05a] &#039;&#039;PhoX&#039;&#039; with Paul Rozière in The seventeen provers of the World, Freek Wiedijk (editor) LNAI 3600 pages 67-71&lt;br /&gt;
&lt;br /&gt;
* [Raf03b] &#039;&#039;System ST&#039;&#039; Schedae Informatica, proceedings of the Chambery-Krawow-Lyon Workshop, Vol. 12, pages 97-112 (June 2003)&lt;br /&gt;
&lt;br /&gt;
* [Raf02c] &#039;&#039;Getting results from programs extracted from classical proofs&#039;&#039;, TCS 2004, volume 323, pages 49-70&lt;br /&gt;
&lt;br /&gt;
* [Raf02b] &#039;&#039;System ST, beta-reduction and completeness&#039;&#039;, presented at LICS 2003, publication IEEE, pages 21-32&lt;br /&gt;
&lt;br /&gt;
* [Raf02a] &#039;&#039;Computer Assisted Teaching in Mathematics&#039;&#039;, with René David, to appear in the proceedings of the Workshop on 35 years of Automath (April 2002, Edingurgh)&lt;br /&gt;
&lt;br /&gt;
* [Raf01d] &#039;&#039;System ST, towards a Type System for Extraction and Proof of Programs&#039;&#039;, Archive for Pure and Applied Logic, 2003, volume 122, pages 107-130&lt;br /&gt;
&lt;br /&gt;
* [Raf01c] &#039;&#039;Apprentissage du raisonnement assité par ordinateur&#039;&#039;, avec René David, Quadrature numéro 45, printemps 2002, pages 25-36). Version courte parue dans la gazette de la SMF, avril 2002, numéro 92, pages 48-56&lt;br /&gt;
&lt;br /&gt;
==== Frederic Blanqui (INRIA, Rocquencourt) ====&lt;br /&gt;
&lt;br /&gt;
Age 38, permanent full-time researcher at [http://www.inria.fr INRIA].&lt;br /&gt;
&lt;br /&gt;
Frederic Blanqui is expert in the following areas:&lt;br /&gt;
* type theory,&lt;br /&gt;
* rewriting theory,&lt;br /&gt;
* termination,&lt;br /&gt;
* functional programming,&lt;br /&gt;
* proof assistants,&lt;br /&gt;
* and formal certification of program properties.&lt;br /&gt;
&lt;br /&gt;
Since September 2008, he is INRIA researcher at [http://liama.ia.ac.cn LIAMA], the Sino-French Laboratory in Computer Science, Automation and Applied Mathematics.&lt;br /&gt;
&lt;br /&gt;
Between 2003 and 2008, he was INRIA researcher at [http://www.loria.fr LORIA], Nancy, in the Protheo research team led by Pr Claude Kirchner, focusing on the use of rewriting techniques for programming, as well as specifying and proving program properties.&lt;br /&gt;
&lt;br /&gt;
Since 2004, he is leading the [http://color.inria.fr CoLoR] project which aims at providing tools for automatically certifying the termination of programs. Since 2007, CoLoR is the best certification back-end in the international [http://termination-portal.org/wiki/Termination_Competition competition on certified termination provers].&lt;br /&gt;
&lt;br /&gt;
In 2007 and 2008, he led the INRIA [http://quotient.loria.fr/ Quotient] project which aims at extending the [http://caml.inria.fr OCaml] programming language with types whose values automatically satisfy equational invariants using the [http://moca.inria.fr Moca] tool.&lt;br /&gt;
&lt;br /&gt;
He supervised 2 master thesis and 3 PhD students on the extension of type theory with decision procedures, the termination of typed higher-order rule-based programs, and the certification of termination proofs.&lt;br /&gt;
&lt;br /&gt;
He did his PhD with Pr Jean-Pierre Jouannaud at University Paris Sud between October 1998 and September 2001 on the combination of type theory and rewriting theory.&lt;br /&gt;
&lt;br /&gt;
Between October 2001 and August 2002, he worked on the certification of cryptographic protocols with Pr Larry Paulson at Cambridge, UK.&lt;br /&gt;
&lt;br /&gt;
Between September 2002 and September 2003, he worked at Ecole Polytechnique in the [http://coq.inria.fr Coq] development team on the extension of the proof assistant Coq with rewriting.&lt;br /&gt;
&lt;br /&gt;
More details on his activities and publications can be found on his [http://www-rocq.inria.fr/~blanqui/ web page] and in his [http://www-rocq.inria.fr/~blanqui/divers/cv.pdf CV].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
International journals with reading committee: 7&lt;br /&gt;
&lt;br /&gt;
International conferences with reading committee: 15&lt;br /&gt;
&lt;br /&gt;
Other publications (thesis, workshops, invited papers, reports, etc.): 15&lt;br /&gt;
&lt;br /&gt;
Prizes: 2001 [http://www.specif.org/ SPECIF] Award for his PhD thesis by the French national society of teachers and researchers in computer science; and 2001 Kleene Award for the best young researcher paper at the IEEE Symposium on Logic in Computer Science ([http://www2.informatik.hu-berlin.de/lics/ LICS]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Five most significant publications in the last 5 years:&lt;br /&gt;
&lt;br /&gt;
* [Bla11] F. Blanqui and A. Koprowski. &#039;&#039;CoLoR: a Coq library on well-founded rewrite relations and its application to the automated verification of termination certificates&#039;&#039;. To appear in Mathematical Structures in Computer Science.&lt;br /&gt;
&lt;br /&gt;
* [BRK10] F. Blanqui, C. Riba and C. Kirchner. &#039;&#039;On the confluence of lambda-calculus with conditional rewriting&#039;&#039;. Theoretical Computer Science 411(37), p. 3301-3327.&lt;br /&gt;
&lt;br /&gt;
* [BR09] F. Blanqui and C. Roux. &#039;&#039;On the relation between sized-types based termination and semantic labelling&#039;&#039;. CSL&#039;09. LNCS 5771.&lt;br /&gt;
&lt;br /&gt;
* [BJS08] F. Blanqui, J.-P. Jouannaud and P.-Y. Strub. &#039;&#039;From formal proofs to mathematical proofs: a safe, incremental way for building in first-order decision procedures&#039;&#039;. TCS&#039;08. IFIP 273.&lt;br /&gt;
&lt;br /&gt;
* [BHW07] F. Blanqui, Thérèse Hardin and Pierre Weis. &#039;&#039;On the Implementation of Construction Functions for Non-free Concrete Data Types&#039;&#039;. ESOP 2007: 95-109.&lt;br /&gt;
&lt;br /&gt;
==== Emmanuel Chailloux (LIP6, Paris) ====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Age 51,  full professor at the University &lt;br /&gt;
Pierre et Marie Curie ([http://www.upmc.fr UPMC - Paris 6]) in Paris France, &lt;br /&gt;
and since October 2006  researcher at the &lt;br /&gt;
[http://www.lip6.fr LIP6] computer science laboratory (UMR 7606), &lt;br /&gt;
in the &amp;quot;Algorithms, Programs and Resolution&amp;quot; team ([http://www-apr.lip6.fr APR]).&lt;br /&gt;
&lt;br /&gt;
His research work is related to design and implementation of programming languages : &lt;br /&gt;
* semantics, &lt;br /&gt;
* types systems, &lt;br /&gt;
* runtime implementation, &lt;br /&gt;
* multicores. &lt;br /&gt;
Most of the recent publications relate to safety-critical software development.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Recent publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[VWC-2011] Vaugon B., Wang P., Chailloux E. &#039;&#039; Les microcontrôleurs&lt;br /&gt;
PIC programmés en Objective Caml&#039;&#039;. Journées des Langages Applicatifs&lt;br /&gt;
(JFLA&#039;2011), janvier 2011.&lt;br /&gt;
&lt;br /&gt;
[WJC-2010] Wang P., Jonquet A., Chailloux E. &#039;&#039;Non-Intrusive&lt;br /&gt;
Structural Coverage for Objective Caml&#039;&#039;.  5th Workshop on Bytecode&lt;br /&gt;
Semantics, Verification, Analysis and Transformation (Bytecode), 2010.&lt;br /&gt;
&lt;br /&gt;
[PAMCCWMC-2009] Pagano B., Andrieu O., Moniot T., Canou B., Chailloux&lt;br /&gt;
E., Wang P., Manoury P., Colaço J.-L. &#039;&#039;Experience Report: Using&lt;br /&gt;
Objective Caml to develop safety-critical embedded tool in a&lt;br /&gt;
certificaiton framework&#039;&#039;.  International Conference of Functional&lt;br /&gt;
Programming (ICFP&#039;09), 2009.&lt;br /&gt;
&lt;br /&gt;
[CBC-2008] Canou B., Balat V., Chailloux E. &#039;&#039;O&#039;Browser : Objective&lt;br /&gt;
Caml on browsers&#039;&#039;. The 2008 ACM SIGPLAN Workshop on ML, 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;HIRONDML: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 2008, 55--69.&lt;br /&gt;
&lt;br /&gt;
[PACCCMW-2008] Pagano B., Andrieu O., Canou B., Chailloux E., Colaço J.-L., Moniot T., Wang P. &lt;br /&gt;
&#039;&#039;Certified development tools implementation in objective caml.&#039;&#039;  &lt;br /&gt;
International Symposium on Practical Aspects of Declarative Languages (PADL 08), 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;Hirondml: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 (2008) 55-69&lt;br /&gt;
&lt;br /&gt;
[HMC-2007] Henry G., Mauny M., Chailloux E. &#039;&#039;Typer la désérialisation&lt;br /&gt;
sans sérialiser les types&#039;&#039;. Technique et Science Informatiques 26, 9&lt;br /&gt;
(2007) 1067-1090.&lt;br /&gt;
&lt;br /&gt;
[CM-2006] Chailloux E., Mauny M. &#039;&#039;Programmation fonctionnelle&#039;&#039;.&lt;br /&gt;
Encyclopédie de l&#039;informatique et des systèmes d&#039;information (2006)&lt;br /&gt;
1016--1027.&lt;br /&gt;
&lt;br /&gt;
==== Tom Hirshowitz (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
34 ans, CR CNRS (informatique) , LAMA&lt;br /&gt;
&lt;br /&gt;
* 2007         CR CNRS au LAMA (UMR 5127) à Chambéry&lt;br /&gt;
* 2004-2007    CR CNRS au LIP (UMR5668) à Lyon&lt;br /&gt;
* 2003-2004    ATER, équipe Plume, LIP, ENS Lyon&lt;br /&gt;
* 2000-2003    Doctorat (dir.: X. Leroy, INRIA Rocquencourt, projet Cristal)&lt;br /&gt;
* 1999-2000    DEA à Paris 7&lt;br /&gt;
* 1996-2000    Ecole Nationale des Ponts et Chaussées&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;10 publications dans des revues et conférences internationales&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;publications choisies&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
# T. Hirschowitz, X. Leroy, and J. B. Wells. Compilation of extended recursion in call-by-value functional languages, PPDP 2003. Version journal dans Higher-Order and Symbolic Computation 22-1. 2009.&lt;br /&gt;
# R. Garner, T. Hirschowitz, and A. Pardon. Variable Binding, Symmetric Monoidal Closed Theories and Bigraphs. CONCUR&#039;09. 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. Contraction-free Proofs and Finitary Games for Linear Logic. MFPS, 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. A Theory for Game Theories. FSTTCS, 2007.&lt;br /&gt;
# T. Hirschowitz, X. Leroy. Mixin Modules in a Call-by-Value Setting, ESOP, 2002, journal version in ACM Transactions on Programming Languages and Systems, 2005.&lt;br /&gt;
&lt;br /&gt;
==== Pierre Hyvernat (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
Age 30, &amp;quot;maître de conférences&amp;quot; at the Université de Savoie (in Chambéry) since September 2006, member of the [http://www.lama.univ-savoie.fr LAMA].&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2005, under the supervision of Thierry Coquand (Chalmers, Göteborg, Sweden) and Thomas Ehrhard (at the time, IML, Luminy, Marseille, France)&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include&lt;br /&gt;
* denotational semantics,&lt;br /&gt;
* type theory and constructive mathematics.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Hyv10b] &#039;&#039;The Size-Change Termination Principle for Constructor Based Languages&#039;&#039; (hal-00547440, submitted)&lt;br /&gt;
&lt;br /&gt;
* [HHy06] with P. Hancock: &#039;&#039;Programming Interfaces and Basic Topology&#039;&#039;. &amp;quot;Annals of Pure and Applied Logic&amp;quot;, volume 137, January 2006,&lt;br /&gt;
&lt;br /&gt;
* [Hyv05] &#039;&#039;Synchronous Games, Simulations and lambda-calculus&#039;&#039;, proceedings of the &amp;quot;GaLoP&amp;quot; workshop, ETAPS 2005. (journal version submitted to Annals of Pure and Applied Logic),&lt;br /&gt;
&lt;br /&gt;
* [Hyv04] &#039;&#039;Predicate Transformers and Linear Logic: yet another Denotational Model&#039;&#039;, Lecture Notes in Computer Science, vol. 3210, September 2004.&lt;br /&gt;
&lt;br /&gt;
==== Alexandre Miquel (PPS, Paris 7) ====&lt;br /&gt;
&lt;br /&gt;
Age 37, &amp;quot;maître de conférences&amp;quot; at the Université Paris-Diderot (Paris 7) since September 2003, member of [http://www.pps.jussieu.fr/ PPS]. Currently CNRS research associate (&amp;quot;délégation&amp;quot;) in the Plume team at the LIP (ENS Lyon) since September 2008.&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2001, under the supervision of Hugo Herbelin (INRIA/LIX) in the Coq team (now TypiCal).&lt;br /&gt;
&lt;br /&gt;
From October 2001 to August 2002 he was postdoc in the Chalmers Institute of Technology (Göetborg, Sweden) under the supervision of Thierry Coquand, and from September 2002 to August 2003 he was &amp;quot;ATER&amp;quot; at the LRI (Orsay).&lt;br /&gt;
&lt;br /&gt;
He is a specialist of the models of type theory (especially the calculus of constructions) and of the correspondence between set theory and type theory. His research interests also include:&lt;br /&gt;
* logic, proof-theory, rewriting,&lt;br /&gt;
* denotational semantics (set- and domain-theoretic),&lt;br /&gt;
* realizability in classical logic.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
His most significant publications are:&lt;br /&gt;
&lt;br /&gt;
* [Miq07] &#039;&#039;Classical program extraction in the calculus of constructions&#039;&#039; (CSL&#039;07),&lt;br /&gt;
&lt;br /&gt;
* [Miq06] with A. Arbiser and A. Ríos. &#039;&#039;A lambda-calculus with constructors&#039;&#039; (RTA&#039;06),&lt;br /&gt;
&lt;br /&gt;
* [Miq04] &#039;&#039;Lambda-Z: Zermelo&#039;s Set Theory as a PTS with 4 Sorts&#039;&#039; (TYPES&#039;04),&lt;br /&gt;
&lt;br /&gt;
* [Miq03] &#039;&#039;A Strongly Normalising Curry-Howard Correspondence for IZF Set Theory&#039;&#039; (CSL&#039;03),&lt;br /&gt;
&lt;br /&gt;
* [Miq00] &#039;&#039;A Model for Impredicative Type Systems with Universes, Intersection Types and Subtyping&#039;&#039; (LICS&#039;00).&lt;br /&gt;
&lt;br /&gt;
==== Christophe Mouilleron (LIP, ENS de Lyon) ====&lt;br /&gt;
&lt;br /&gt;
Age 26, PhD student in the Arenaire team at the LIP (ENS de Lyon) since September 2008. He works under the supervision of Claude-Pierre Jeannerod (INRIA/LIP) and Gilles Villard (CNRS/LIP).&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include :&lt;br /&gt;
* computer arithmetic,&lt;br /&gt;
* code generation,&lt;br /&gt;
* formal proof of numerical properties in programs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [MouRev10] C. Mouilleron and G. Revy. &#039;&#039;Automatic Generation of Fast and Certified Code for Polynomial Evaluation.&#039;&#039; (submitted, available as ensl-00531721)&lt;br /&gt;
&lt;br /&gt;
* [JeaMou10] C.-P. Jeannerod and C. Mouilleron. &#039;&#039;Computing Specified Generators of Structured Matrix Inverses.&#039;&#039; (ISSAC&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [BJJK+10] C. Bertin, C.-P. Jeannerod, J. Jourdan-Lu, H. Knochel, C. Monat, C. Mouilleron, J.-M. Muller, and G. Revy. &#039;&#039;Techniques and tools for implementing IEEE 754 floating-point arithmetic on VLIW integer processors.&#039;&#039; (PASCO&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [LTdD+10] V. Lefèvre, P. Théveny, F. de Dinechin, C.-P. Jeannerod, C. Mouilleron, D. Pfannholzer, and N. Revol. &#039;&#039;LEMA : Towards a Language for Reliable Arithmetic.&#039;&#039; (PLMMS&#039;10)&lt;br /&gt;
&lt;br /&gt;
===Relevant publications by non participants to the project ===&lt;br /&gt;
&lt;br /&gt;
Here are some publication or resources of interest for the project:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Laguage design and theory:&#039;&#039;&#039;&lt;br /&gt;
* [SOW97] Martin Sulzmann, Martin Odersky, Martin Wehr, &#039;&#039;Type inference with constrained types&#039;&#039;, TAPOS, 1997.&lt;br /&gt;
* [HW04] Christian Haack and J. B. Wells, &#039;&#039;Type error slicing in implicitly typed higher-order languages&#039;&#039;, Sci. Comput. Programming, 50:189-224, 2004.&lt;br /&gt;
* [Ruy06] Frédéric Ruyer, &#039;&#039;Preuves, types et sous-type&#039;&#039;, phd 2006 directed by C. Raffalli.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Termination:&#039;&#039;&#039;&lt;br /&gt;
* [LJ01] Lee, Jones, et al. &#039;&#039;The size-change principle for program termination&#039;&#039; - ACM SIGPLAN Notices - 2001&lt;br /&gt;
* [Abel04] Andreas Abel, &#039;&#039;Termination Checking with Types&#039;&#039; ,Special Issue: Fixed Points in Computer Science (FICS&#039;03 and RAIR&#039;04)&lt;br /&gt;
* [Bar04]   G. Barthe, M. J. Frade  and E. Giménez, L. Pinto and T. Uustalu, &#039;&#039;Type-Based Termination of Recursive Definitions&#039;&#039;, 2004, Mathematical Structures in Computer Science.&lt;br /&gt;
* [Gie06] J. Giesl, S. Swiderski, P. Schneider-Kamp, and R. Thiemann &#039;&#039;Automated Termination Analysis for Haskell: From Term Rewriting to Programming Languages&#039;&#039;, Proceedings of the 17th International Conference on Rewriting Techniques and Applications (RTA-06), Lecture Notes in Computer Science 4098.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;the Clean language:&#039;&#039;&#039;&lt;br /&gt;
* [AGR92] Peter Achten, John van Groningen and Rinus Plasmeijer (1992). &#039;&#039;High-level specification of I/O in functional languages&#039;&#039;, Proc. of the Glasgow workshop on Functional programming, ed. J. Launchbury and P. Sansom, Ayr, Scotland, Springer-Verlag, Workshops in Computing, pp. 1-17.&lt;br /&gt;
* [AcP95] Peter Achten and Rinus Plasmeijer (1995). &#039;&#039;The Ins and Outs of CONCURRENT CLEAN I/O&#039;&#039;, Journal of Functional Programming, 5, 1, pp. 81-110.&lt;br /&gt;
* [AcP97] Peter Achten and Rinus Plasmeijer (1997). &#039;&#039;Interactive Functional Objects in CLEAN&#039;&#039;, Proc. of the 1997 Workshop on the Implementation of Functional Languages (IFL&#039;97), ed. K. Hammond Davie, T., and Clack, C., St.Andrews, Scotland,&lt;br /&gt;
* [VPA07] Edsko de Vries, Rinus Plasmeijer, and David M. Abrahamson, &#039;&#039;Uniqueness Typing Simplified, by Edsko de Vries&#039;&#039;,&lt;br /&gt;
* [http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf the language report] by Rinus Plasmeijer and Marko van Eekelen,&lt;br /&gt;
* [http://clean.cs.ru.nl/ the language homepage].&lt;br /&gt;
&lt;br /&gt;
===Involvement of project participants to other grants, contracts, etc …===&lt;br /&gt;
&lt;br /&gt;
* Frederic Blanqui is involved in the Sino-French ANR SIVES 2009-2011 on SImulation and Verification based platform for developing Embedded Systems.&lt;br /&gt;
* Emmanuel Chailloux is member of the ANR PWD (&amp;quot;Programmation du Web Diffus&amp;quot;), whose leader is Manuel Serrano (Inria), and the FUI [http://opengpu.net/ OpenGPU project].  &lt;br /&gt;
* Tom Hishowitz is involved in the ANR PiCoq the ANR proposals RÉCRÉ and CATHRE.&lt;br /&gt;
* Pierre Hyvernat is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Alexandre Miquel is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Christophe Raffalli is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Remark: the interaction with PML and RÉCRÉ is natural because the proof technics used for ensuring some of the properties of the language PML is réalizability which is one of the théma of the ANR proposal RÉCRÉ.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5077</id>
		<title>ANR PML</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5077"/>
		<updated>2011-01-13T11:09:58Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Task 5 - validation (transverse task) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;URL of PML project: &amp;lt;tt&amp;gt;http://lama.univ-savoie.fr/tracpml&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Context and positioning of the proposal==&lt;br /&gt;
&lt;br /&gt;
Ever since FORTRAN appeared fifty years ago, programming languages have been evolving rapidly. These languages now include more and more sophisticated concepts like &amp;quot;objects&amp;quot;, &amp;quot;type inference&amp;quot;, &amp;quot;modules&amp;quot;... However, this richness is also what makes it more and more complex to train programmers and makes it difficult for them to keep up with the innovations and changes in programming languages.&lt;br /&gt;
&lt;br /&gt;
Another orthogonal phenomenon is the emergence of formal methods used in conjunction with various programming languages to test, check or prove software. This introduces another layer to languages in order to write specifications, and sometimes yet another one for proofs. Learning a programming language together with the associated specification/proof languages can take an important effort.&lt;br /&gt;
&lt;br /&gt;
Projects such as [http://www.cs.utexas.edu/users/moore/acl2/ ACL2], the successor of  [http://www.cs.utexas.edu/users/boyer/ftp/nqthm nqthm, the Boyer-Moore theorem prover] uses a rather simple language (namely LISP) both as a programming language and specification language, allowing to keep a unity in the system. Unfortunately, LISP is somewhat limited both as a programming language (no good treatment of sum type, no module system) and a specification language (very limited quantification). Moreover, LISP has no compile-time type-checking, which has proved very useful to detect bugs and automatically assert properties.&lt;br /&gt;
&lt;br /&gt;
The aim of this project is to build a very powerful language (with no loss of expressive power compared to state of the art languages) based on a very small number of simple features. We think this will be possible thanks to recent progress both in the semantics of programming languages and the apparition of new algorithms for type inference based on constraints-solving. In fact, we propose in [RAF10b] an innovative concept derived from the later to enable this: constraints-checking.&lt;br /&gt;
&lt;br /&gt;
Moreover, the language will be used not only as a programming language and a specification language (like in ACL2), but also as the proof language. This is natural for an ML-like language because pattern-matching is a natural and powerful way to make a proof by case analysis. This also means that our tool will follow the &#039;&#039;KISS&#039;&#039; philosophy: relatively few (unified) features, yet powerful.&lt;br /&gt;
&lt;br /&gt;
The idea of a new language arose from the discovery of a new typing algorithm [RAF10b] whose implementation gave birth to a first implementation of PML (Proved ML) by Christophe Raffalli. This implementation is already available from [http://www.lama.univ-savoie.fr/~pml the web page of the language]. However, turning PML into a real tool requires a lot of research and implementation work and this is why we request the help of the ANR. Some of the goals are highlighted in the next sections.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML aproach to proofs of specification is unique&#039;&#039;&#039; PML has no dedicated proof language, but the user can still write proofs! Existing programming languages supporting specifications use two alternatives: automated proofs (ACL2, Why) or proof obligations that the user can prove using specific language (Coq extraction, Focalize, Why). Several systems provide both, the manual proofs being used only when automation fails. PML is very different in spirit: it introduces a new instruction, written with a &amp;quot;scissors symbol&amp;quot; &amp;lt;tt&amp;gt;&#039;&#039;&#039;8&amp;lt;&#039;&#039;&#039;&amp;lt;/tt&amp;gt; to express that the corresponding position in the program is &#039;&#039;dead&#039;&#039;, meaning that it can not be reached during evaluation. This condition is checked by a terminating variant of the Knuth-Bendix completion algorithm. This is rather simple and therefore easier to trust than modern decision procedures. However, it only solves trivial cases: to write complex proofs, the user just uses the same syntax as for programs to do case analysis or induction (&#039;&#039;ie.&#039;&#039; recursive definitions). This means that the user does not need learn a specific proof language and hopefuly implies that PML is easier to learn and probably more adapted to industry that previous solutions.&lt;br /&gt;
&lt;br /&gt;
The logic of PML is just the equational theory of its programming language; and we use variants of Knuth-Bendix completion as a proof-checker. The first experiments with the current implementation are promising. However, Knuth-Bendix procedure in the context of ML is a complex and new research problem. A lot more work is needed, for instance to handle proofs in arithmetic which occur quite often. Here is an example of a proof in arithmetic, checked in the current version of PML. This is not completely satisfactory (hard to write), but shows the use of the language for both proofs and programs and the use of recursive functions for inductive proofs:&lt;br /&gt;
&lt;br /&gt;
  val rec mul_associative x y z |- (x * y) * z == x * (y * z)&lt;br /&gt;
    proof match x with&lt;br /&gt;
      Z[] -&amp;gt; 8&amp;lt; (* trivial case handled automatically by Knuth-Bendix *)&lt;br /&gt;
    | S[x&#039;] -&amp;gt;&lt;br /&gt;
      let _ = mul_associative x&#039; y z in (* There is a syntactic sugar for that... *)&lt;br /&gt;
        (* this adds the fact that (x&#039;*y) * z == x&#039; * (y*z) to the environment *)&lt;br /&gt;
 &lt;br /&gt;
      let _ = mul_right_distributive y (x&#039; * y) z in&lt;br /&gt;
        (* this adds the fact that (y + x&#039;*y) * z == y*z + (x&#039;*y)*z *)&lt;br /&gt;
 &lt;br /&gt;
        (* the environment now contains enough information for Knuth Bendix to handle the rest:&lt;br /&gt;
         *    - x*(y*z)  ==  y*z + x&#039;*(y*z)  : by definition&lt;br /&gt;
         *    - x*y == y + x&#039;*y : by definition&lt;br /&gt;
         *      and so (x*y)*z == (y + x&#039;*z)*z&lt;br /&gt;
         *    - (x&#039;*y) * z == x&#039; * (y*z)  :  by the recursive call to mul_associative&lt;br /&gt;
         *    - (y + x&#039;*y) * z == y*z + (x&#039;*y)*z : by the call to mul_right_distributive  *)&lt;br /&gt;
      8&amp;lt;&lt;br /&gt;
&lt;br /&gt;
Moreover, this style of proof is declarative and relatively readable (like Mizar proofs) while concise at the same time. This is very important when you want to maintain large developments.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;PML is different from the other modern programming languages&#039;&#039;&#039; because its design focuses on a few powerful concepts. One consequence is that it is more difficult for a compiler to produce efficient code. In particular, since PML unifies several notions of products (modules, tuples and records), there is no simple way to choose the internal representation of a product, especially with implicit subtyping. Writing a good compiler for PML will thus require more complex and original optimization schemes (probably driven by typing) than languages like OCaml or Haskell. A Polish student (Wojciech Matyjewicz) is just starting a PhD on this very topic.&lt;br /&gt;
&lt;br /&gt;
Here is a simple example, accepted by the current version of PML, demonstrating product type, sum type and subtyping. We define ternary trees as an extension of binary trees with an implicit subtyping&lt;br /&gt;
relation (all functions accepting binary_trees will accept ternary trees, by ignoring the &amp;lt;tt&amp;gt;middle_son&amp;lt;/tt&amp;gt;):&lt;br /&gt;
&lt;br /&gt;
 type rec binary_tree (A) =&lt;br /&gt;
   [ Nil[] | Node[A with left_son : binary_tree(A); right_son : binary_tree(A)] ; ]&lt;br /&gt;
 type rec ternary_tree(A) =&lt;br /&gt;
   binary_tree({ A with middle_son : ternary_tree(A) ;})&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML requires a termination criterion&#039;&#039;&#039; because a proof by induction will just be a normal recursive program. Such a program has to be well-founded in order to correspond to a valid proof. A subset of Haskell can now use the Aprove tool to establish termination for simple programs. However, we want the test to be fully integrated with the language, and be compatible with very modular programs. At the moment, these goals seem difficult to achieve with Aprove or other external termination checkers. A first termination criterion based on Lee, Jones &amp;amp; Ben-Amram&#039;s &amp;quot;size-change termination principle&amp;quot; was implemented by Pierre Hyvernat [Hyv10b]. While this test is quite powerful, it is necessarily incomplete, and quite some work is required to make termination proofs of complex programs tractable.&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical description==&lt;br /&gt;
&lt;br /&gt;
===Background, state of the art===&lt;br /&gt;
&lt;br /&gt;
====Programming language====&lt;br /&gt;
&lt;br /&gt;
The ML programming language, created by Robin Milner &amp;lt;em&amp;gt;et al&amp;lt;/em&amp;gt; in the 80&#039;s has two major distinctive features:&lt;br /&gt;
* Algebraic data-types and pattern matching: data types are basically all constructed using fixpoint, cartesian product (product types) and disjoint union (sum types).&lt;br /&gt;
* Static type inference: the type of every piece of code is automatically inferred using Hindley-Milner algorithm (HM). By by construction, once compiled, an ML program can not crash (no segmentation fault). More precisely, when we do not use unsafe features of the language (like interface with unsafe libraries written in C), if an ML program produces a segmentation fault, then there is a bug in the type-checker or the compiler.&lt;br /&gt;
&lt;br /&gt;
Recent progress in type inference algorithm uses constraint solving. This means that the type system can be described in first-order predicate logic in such a way that a type inference problem is a formula written in a decidable fragment of first-order predicate logic (often the purely existential fragment). Hence, any constraint solver can be turned into a type-checker for ML. These approach is known as HM(X) (see [SOW97]).&lt;br /&gt;
&lt;br /&gt;
There are two problems with this approach:&lt;br /&gt;
* The complexity of constraint solving can be too high for practical use, especially when using a general purpose constraint solver. To our knowledge, there are currently no mainstream implementation of ML based on HM(X).&lt;br /&gt;
* HM(X) does not completely solve the problem of subtyping. The language to express the types constructed by the constraint solver is the same as the language of types used by programmers. With constraints &amp;lt;math&amp;gt;\alpha \subseteq \beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\alpha \subseteq \gamma&amp;lt;/math&amp;gt; for three types &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\gamma&amp;lt;/math&amp;gt;, the most natural solution is &amp;lt;math&amp;gt;\alpha = \beta \cap \gamma&amp;lt;/math&amp;gt;. This implies that intersection needs to be part of the language for types. This means that constraints such as &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \delta&amp;lt;/math&amp;gt; may also appear and they are problematic to deal with. Similar reasoning shows that constraints of the form &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \beta&#039; \cup \gamma&#039;&amp;lt;/math&amp;gt; may appear, increasing the complexity of constraint solving by an exponential factor.&lt;br /&gt;
&lt;br /&gt;
PML&#039;s approach is to replace type-inference by &#039;&#039;constraint &amp;lt;u&amp;gt;checking&amp;lt;/u&amp;gt;&#039;&#039; rather than constraint solving: we only check that the constraints are satisfiyable in some model. Type-checking in the current implementation of PML can be seen as a black box ensuring that nothing can go wrong during execution. Moreover, since we do not need to write solutions for the constraints, the language for types can be relatively simple. In fact, the types written by the programmer aren&#039;t even the actual type constraints that are checked: they are syntactic sugar for the projection operator onto the intended type (giving for free nice feature like higher-order parametric types, that is types with parameters which may be themselves types with parameters). In other words, the expression &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; is a synonym for &amp;lt;tt&amp;gt;(id_nat x)&amp;lt;/tt&amp;gt; where&lt;br /&gt;
  val rec id_nat x = match x with&lt;br /&gt;
      Z[] -&amp;gt; Z[]&lt;br /&gt;
    | S[x&#039;] -&amp;gt; S[id_nat x&#039;]&lt;br /&gt;
is defined internally by PML. The constraint generated by &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; mean exactly that &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is of type &amp;lt;tt&amp;gt;nat&amp;lt;/tt&amp;gt;...&lt;br /&gt;
&lt;br /&gt;
With this approach, we loose type-inference and the ability to display types in error messages. Nevertheless, PML error reporting is quite helpful because, in case of problem, it displays three positions in the code and an error message like this &amp;lt;tt&amp;gt;error at position 1, label &amp;quot;id&amp;quot; projected at position 2 do not appear in the value constructed at position 3&amp;lt;/tt&amp;gt;. This kind of error message is in fact of bounded length and often more useful than OCaml or SML messages. We can understand this as showing three points in the &#039;&#039;slice&#039;&#039; of the error, as introduced by Joe Wells in [HW04].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Proof assistant====&lt;br /&gt;
&lt;br /&gt;
Proof assistants have evolved rapidly since Automath in the 70th. Two main trends coexist: automated proof assistants such as ACL2, PVS and &#039;&#039;safe&#039;&#039; ones such as Coq, Isabelle, PhoX, Lego, HOL, Matita, &amp;lt;em&amp;gt;etc.&amp;lt;/em&amp;gt; The former incorporate very sophisticated automated deduction strategies, with no &#039;&#039;certificate&#039;&#039; for the validity of the proof, while the later require all proofs to be done in a specific framework (like natural deduction or type theory) allowing for a simple check of the proof. The gap between the two approaches tend to be reduced by the emergence of complex tactics (for Coq or Isabelle mainly) which build proofs for the user. For instance Zenon is an advanced automated first-order theorem prover outputing a Coq proof.&lt;br /&gt;
&lt;br /&gt;
The common defect of all these proof assistants is that a proof can not be written nor understood without running the proof assistant. Some proof assistants such as Mizar or Alf do not follow exactly the above scheme: Mizar has a declarative style for proof which is (in theory) readable by a human and checked by a limited checker. (This proof style has been adapted to Coq and Isabelle.) Unfortunately, there is no formal description of the Mizar proof checker. Alf on the other hand is based on proof theory and requires the user to basically write the complete proof tree just leaving out a few details. The logic is very well formalized and simple, but writing proof is tedious and not similar to the usual practice of informal mathematics.&lt;br /&gt;
&lt;br /&gt;
This picture of the world of proof assistants shows that some fundamental work is needed. In the current version of PML, the logic is just an equational theory of the underlying programming language. This is easily described formally. The proof engine is, like in Mizar, a limited automated checker inspired by the Knuth-Bendix completion algorithm (KB). The completion algorithm used in PML had to be adapted to the higher-order constructs of ML-like languages and restricted to ensure termination and an acceptable complexity. The current limitation is probably too strong: it is limited to closed terms and cannot use universal theorems automatically (as in the first example of section 1, where one has to give explicitly the argument to use distributivity).&lt;br /&gt;
&lt;br /&gt;
Nevertheless, preliminary examples in the current version shows that the approach is worth trying: proofs are concise and readable once you know the language. A very encouraging point is that all examples where written without interface. This really means that proofs are readable without the help of a computer.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Rationale highlighting the originality and novelty of the proposal===&lt;br /&gt;
&lt;br /&gt;
The final objective of our project would be a full PML compiler, bootstrapped and completely proved with itself (full bootstrap). This does not exist for any language and is far too ambitious for a four years project.  More realistically, we plan to produce a compiler for PML, written in PML, but not proved in PML yet.&lt;br /&gt;
&lt;br /&gt;
We also want to develop proof-checking in such a way as to allow very elegant proofs, supporting the feasibility of a full bootstrap by various examples, some of them being near to industrial application, some others being algorithms coming from implementation of programming languages.&lt;br /&gt;
&lt;br /&gt;
We have focused the existing development on the quality of the language both for proofs and programs. By quality, we mean easy to understand and write (and therefore, easy to learn). We think that using the programming language as a proof language could make formal methods more attractive to the industry without the defect of systems like PVS and ACL2 where the automated tactics replace the need for a proof language, but are sometimes hard to control and use. For instance, finding the right &#039;&#039;lemmas&#039;&#039; to make a proof possible in ACL2 is quite difficult.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other proof systems devoted to programming.&#039;&#039;&#039; Many other proof systems have been used or specifically developed&lt;br /&gt;
to allow the production of certified code: extraction in Coq, Why with its automated prover Who from the Proval project, Focalize, PVS, ATS, ... None of these system uses the programming language as a proof language. They all have a dedicated language for proofs and even if some of them like Focalize or Coq extraction using a Mizar style mode for proof, have readable proofs, learning the proof language is never trivial. Other systems like PVS, ATS, Why using Who rely on automated deduction. In those cases, the behavior of the automated prover is always hard to predict.&lt;br /&gt;
&lt;br /&gt;
Another selling point is that the logic and programming language are fully integrated. This is not a two level systems like most systems (but not all, ACL2 for instance is fully integrated). In PML, the statements of theorems and their proofs are expressions at the same level than programs. This means that a program can contain specifications that contains program definitions in their statement or proof and so on. This is generally not possible (even in ACL2) and makes it possible to write modules with their specifications.&lt;br /&gt;
&lt;br /&gt;
On of the key idea for this project is that any ML-like programming language has all the features needed for a proof language: case analysis via pattern matching and exception handling, induction, calling previously defined program/theorems. This means that it is natural to explore this direction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other programming languages&#039;&#039;&#039;. Another key idea in PML is to develop the language and its proof-checker together. This has a great impact on the design of PML. Let&#039;s illustrate this with a concrete example: exception handling. In ML, there is a&lt;br /&gt;
  try P with e -&amp;gt; R&lt;br /&gt;
but, this is not sufficient to do case analysis on the fact that a program &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises or not an exception. In particular, &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; can be the proof just in case &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises an exception. However there is no place holder for the normal case (without exception). This is why we had to introduce a&lt;br /&gt;
  let try x = P in Q with e -&amp;gt; R&lt;br /&gt;
where &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; is evaluated only when &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; reduces to a value.&lt;br /&gt;
&lt;br /&gt;
A great number of decisions on the language design comes from the interaction between the development of the programming language and its proof-checker. Another key feature of PML, which makes the project original even as a programming language compared to many other projects of programming language research (GALLIUM, Haskell, Scala, ...) is the use of constraint checking. This choice arises from the fact that we want a language as small as possible, because a proof-checker is complex and therefore, we want to fully unify all sorts of Cartesian product including modules, records, tuples and variant with multiple argument. This is already achieved in the current implementation of PML and to my knowledge, no ML like language have a unique but still powerful notion of Cartesian product.&lt;br /&gt;
&lt;br /&gt;
All the systems previously mentioned allow to prove programs in limited subsets of existing languages like ML or Haskell. The prover has to find ways to deal with those languages&#039; defects rather than improve them...&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical program, project management==&lt;br /&gt;
&lt;br /&gt;
===Specific aims of the proposal===&lt;br /&gt;
&lt;br /&gt;
As said in the previous section, the final objective would be to have a fully bootstrapped PML language: this would mean that PML is entirely written and proved in PML. This would be too ambitious at first, and we chose to focus here on the design of the language plus a proof of concept, that is compilation and proof of various examples, searching to do our best on the following points:&lt;br /&gt;
&lt;br /&gt;
* Natural way of writing programs (Task 1)&lt;br /&gt;
* Efficiency of the code generated by the compiler, despite the heavily use of subtyping (Task 3)&lt;br /&gt;
* Readable and short proofs (Task 1, Task 4)&lt;br /&gt;
* Efficiency of type-checking and compilation (Task 2 and 6)&lt;br /&gt;
* Efficiency of proof-checking (Task 4 and 6)&lt;br /&gt;
* All of the above points need testing, and we created a transverse fifth task for that.&lt;br /&gt;
&lt;br /&gt;
===Project management===&lt;br /&gt;
&lt;br /&gt;
We plan to have one 3 days workshop per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems. We already have the agreement of some people to participate in such meetings: Joe Wells, Assia Mahbouby, Andreas Abel, ...&lt;br /&gt;
We plan to have one 3 days meetings per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We will also organize two project meeting per year, just to keep track of progress, share idea and organize the above workshop and other invitation.&lt;br /&gt;
&lt;br /&gt;
We want also to organize visits of one or two members of the project to visit researcher on similar topic (typically a member of the project could visit one of the invited speaker of our workshop). Members of the project should also travel to conference on the subject like POPL, LICS, CSL, TYPES or the recently created CPP (first conference in 2011).&lt;br /&gt;
&lt;br /&gt;
===Detailed description of the work organized by tasks===&lt;br /&gt;
&lt;br /&gt;
====Task 1 - theoretical work, design of the language ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Alexandre Miquel, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.a - Correctness of the constraint checking algorithm&#039;&#039;&#039; (delivered&lt;br /&gt;
09/2012): [RAF10b] already cover the correctness without polymorphism. A draft version of &lt;br /&gt;
the correctness proof with polymorphism does exist but needs more work. The &lt;br /&gt;
main open problem here is the interaction with the termination-check. The current work &lt;br /&gt;
proves that when constraints are checked, the program can only loop via recursive definitions.&lt;br /&gt;
Then, we would like to prove that the program is terminating if recursive definitions are accepted by the &lt;br /&gt;
termination checker. However, this is non trivial.&lt;br /&gt;
&lt;br /&gt;
This being a central piece of PML, it should be also one&lt;br /&gt;
of the first tests for PML in task 5. We could also prove this part of PML in&lt;br /&gt;
Coq (in fact 2 provers proving themselves and each other correct is a much&lt;br /&gt;
stronger warranty than one prover proving itself).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.b - Consistency of proof-checking&#039;&#039;&#039; (beginning 09/2011, delivered before 09/2013 for the core of the language): This is essential for clearly defining the logic of PML and prove its consistency. This should not be too hard for the core of the language. However, this proof has to be extended to take into account all future extensions of the language and could be seen as a &#039;&#039;permanent task&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.c - Adaptation of uniqueness typing to the context of constraint checking&#039;&#039;&#039; (beginning 09/2012, delivered 01/2014): The current version of PML is a pure functional programming language, with no imperative feature. This is problematic, because input/output is necessary for real programs and affectations are required for efficiency especially when using large arrays. We plan to adapt the approach of the [http://clean.cs.ru.nl/ Clean language] [AGR92], [AcP95], [AcP97], [VPA07]. In Clean, all programs can be analyzed as purely functional programs, but the type system can check that some data are not used any more and reuse the place in memory for other data (allowing affectation). For instance, in such a context writing in a file &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; can be written as &amp;lt;tt&amp;gt;let f&#039; = write f str in ...&amp;lt;/tt&amp;gt;, but the compiler must check that &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; will not be used anymore implying the equivalence between the standard imperative semantics of writing to file and the purely functional semantics used by proofs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.d - Private, abstract and existential types.&#039;&#039;&#039; (beginning 09/2011, delivered&lt;br /&gt;
09/2012 for private type, beginning 09/2012, delivered&lt;br /&gt;
09/2013 for existential types and beginning 09/2013, delivered 09/2015 for abstract&lt;br /&gt;
types)&lt;br /&gt;
 &lt;br /&gt;
Abstract data types hide the definition of a data type and allow the user of&lt;br /&gt;
a library to be sure that his code will continue to work even if the internal&lt;br /&gt;
representation of data are changed. In the context of constraint-checking in&lt;br /&gt;
PML, adding abstract data types seems to be a challenging task. Moreover,&lt;br /&gt;
abstract data-types are a form of existential quantification over types and&lt;br /&gt;
could raise some consistency issues. We hope to find a way to incorporate&lt;br /&gt;
abstract types in PML without loosing coherence.&lt;br /&gt;
 &lt;br /&gt;
A first step would be private data types. They are a very simple yet very powerful mechanism for easily&lt;br /&gt;
ensuring invariants on all values of a data type. This mechanism is as&lt;br /&gt;
follows: the compiler simply checks that the constructors of a data type are&lt;br /&gt;
not used for constructing values. Values are constructed by using construction&lt;br /&gt;
functions, like with abstract data types. However, unlike with abstract data&lt;br /&gt;
types, constructors can still be used as patterns for defining functions by&lt;br /&gt;
pattern-matching. Hence, a library on a private data type is not closed but&lt;br /&gt;
can be extended easily. Private data types are therefore an important and very&lt;br /&gt;
useful feature for defining data structures with complex invariants and&lt;br /&gt;
proving their correctness more easily. They have been implemented in OCaml by&lt;br /&gt;
Pierre Weis and are described in Frédéric Blanqui, Thérèse Hardin and Pierre&lt;br /&gt;
Weis&#039; ESOP&#039;07 paper [BHW07].&lt;br /&gt;
&lt;br /&gt;
A second step would be existential types, which are very similar to abstract types,&lt;br /&gt;
but with no free name for the abstract type. On a logical level, they do imply an existential quantification over types&lt;br /&gt;
which has to be limited to ensure consistency. However existential types do not require the type to have a free name, which corresponds in logic to a definite description operator (similar to Hilbert&#039;s epsilon operator), and this, being connected to the axiom of choice (over types), may be really problematic for consistency. Some work related to this exists in the phd thesis of F. Ruyer, a former student of C. Raffalli [Ruy06].&lt;br /&gt;
&lt;br /&gt;
====Task 2 - termination====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Pierre Hyvernat&lt;br /&gt;
&lt;br /&gt;
Participants: Christophe Raffalli, Andreas Abel, Frederic Blanqui&lt;br /&gt;
&lt;br /&gt;
Remark: this is an essential task, running during the 4 years. There will always be some embarrassing examples that do not work, but could work... both for the core and auxiliary criterion (see below for the distinction) meaning that this research field will remain open forever.&lt;br /&gt;
&lt;br /&gt;
Even if it might be counter-intuitive at first, it is often necessary to write programs whose execution can be infinite. For example, any kind of &amp;quot;server&amp;quot;, or almost any interactive program might have infinite executions. Even in purely mathematical setting, it can be interesting to have intermediary non-terminating functions. Consider a function outputting the stream of prime numbers : even if this function is non-terminating, we might use it in a terminating manner in a proof by requesting the &#039;&#039;n&#039;&#039; first prime numbers.&lt;br /&gt;
&lt;br /&gt;
Since PML uses full recursion (keyword &amp;lt;tt&amp;gt;rec&amp;lt;/tt&amp;gt;), writing such programs is easy. On the other hand, the notion of &amp;quot;terminating&amp;quot;, or &amp;quot;well-founded&amp;quot; recursive function isn&#039;t part of the core of PML: such programs are just special cases of recursive programs. The user will have to specify which functions are in fact terminating and might have to prove it himself when PML cannot infer termination automatically.&lt;br /&gt;
&lt;br /&gt;
Proofs of specifications are just PML programs, and those cannot be allowed to run infinitely. More precisely, even if proof will never be run at all (no computational content), they are required to be well-founded. The consistency of PML relies on this. In order to relieve the user from proving that all proofs are in fact terminating, PML should offer a way to check automatically that (some) functions are terminating. Because the halting problem is undecidable, it is hopeless to do that in all generality, but this is seldom necessary: many proofs terminate for obvious reasons. PML should only work for most of the functions, most of the time (rather than work for all the functions, all the time...)&lt;br /&gt;
&lt;br /&gt;
Technically speaking, PML can infer an error called &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; when it encounters a program which, it thinks, may not terminate. Such an error cannot be captured: this is an error rather than an exception. The property we need to guarantee is that if PML doesn&#039;t infer the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; possible, then the program in question does indeed terminate. If the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; is possible for a terminating function, the user can still provide PML with a proof that this error is never raised. PML current syntax for that is &amp;lt;tt&amp;gt;[p proof ... ]&amp;lt;/tt&amp;gt; where &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; is a term and &amp;lt;tt&amp;gt;...&amp;lt;/tt&amp;gt; is a proof that &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; doesn&#039;t raise any exception nor error (this is the desired property for proofs).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.a - Core termination criterion&#039;&#039;&#039; (delivered 09/2010)&lt;br /&gt;
&lt;br /&gt;
This first test is now part of PML. Since primitive recursive function isn&#039;t enough in practice, even for proofs, a subtler and more powerfull termination criterion has been implemented. This is an extension of the &amp;quot;size change principle&amp;quot; of Lee, Jones and Ben-Amram [LJ01]. This test successfully checks termination for primitive recursion, lexicographic ordering and permutation of arguments and thus covers most simple practical cases. The implementation is quite similar to the original size-change principle, but the proof of correctness is surprisingly more difficult: see [Hyv10b].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.b - Improvement of the core termination criterion&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
The size-change principle is simple and powerful, but many cases occurring in practice aren&#039;t tagged as terminating. We plan to adapt to PML a termination criterion based on the technique of type-based termination, which allow for recursive calls through size preserving functions such as &amp;lt;tt&amp;gt;List.map&amp;lt;/tt&amp;gt;. There are several possibilities, ranging from simple systems such as the one developed by Abel (RAIRO&#039;04) [Abel04], Barthe et al (MSCS&#039;04) [Bar04] or Blanqui (RTA&#039;04, CSL&#039;05) [Bla04, Bla05c], to the very rich system of Blanqui and Riba (LPAR&#039;06) [BlR06]. In the latter, given for each function some formula in Presburger arithmetic describing how the size of the output is related to the size of the inputs (the correctness of which can be checked automatically), the termination follows from the fact that recursive calls are done on strictly decreasing arguments, using for instance lexicographic or multiset comparisons together with linear combinations of the arguments. Intermediate systems, such as the one of Barthe, Grégoire and Riba (CSL&#039;08) [BGR08] which is powerful but with a lower complexity than Presburger arithmetic, have also to be considered.&lt;br /&gt;
&lt;br /&gt;
This development looks rather orthogonal to the implemented criterion and might require small modification of other parts of PML in order to get the appropriate information. On a different level, slight extensions should be added to the existing criterion to enhance its complexity on some specific examples that are recognized as termination, but not in a reasonable time.&lt;br /&gt;
&lt;br /&gt;
This core termination needs to reach an acceptable compromise between power and simplicity. In particular, the most complex developments may not find their way into the core termination criteria, but rather be used in the next task...&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.c - Use of external provers&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
In order to circumvent the limitations of the core termination criterion, we propose to use external powerful termination provers like [http://aprove.informatik.rwth-aachen.de/ Aprove] or [http://colo6-c703.uibk.ac.at/ttt2/ TTT2] that implement and combine many other termination techniques. To this end, we can define translations from PML programs to one or more of the possible formats currently used in the [http://termination-portal.org/wiki/Termination_Competition annual international competition on termination] and in particular: first-order rewrite systems (TRS), dependency pair problems (DP problem), higher-order rewrite systems (HOTRS) or Haskell programs. In particular, we could reuse some of the techniques used for converting Haskell programs into first-order DP problems in [Gie06].&lt;br /&gt;
&lt;br /&gt;
But to which extent can we trust the results of these provers? Hopefully, now, many termination provers provide certificates in a format called [http://cl-informatik.uibk.ac.at/software/cpf/ CPF] that can be checked by certified, dedicated tools like [http://cl-informatik.uibk.ac.at/software/ceta/ CeTA], [http://color.inria.fr/ Rainbow] or [http://a3pat.ensiie.fr/ CiME3].&lt;br /&gt;
&lt;br /&gt;
The most pragmatic route is simply to trust those tools and concentrate on proving that the translation from (restricted) PML code to the input language is indeed correct. Of course, the ideal solution would be to be able to translate the external certificates into an equivalent PML program whose termination can be infered by the core criterion. The complexity of tools like [http://aprove.informatik.rwth-aachen.de/ Aprove] makes it look very difficult and it is probably hopeless to do that in a general manner.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.d - Modularity and termination&#039;&#039;&#039; (beginning 09/2013, never ending)&lt;br /&gt;
&lt;br /&gt;
The core termination prover does not use the definition of functions to prove their termination, but only information gathered from the typing constraints. When using external prover, for large development, one also would like to avoid sending a large piece of code to the external prover. &lt;br /&gt;
&lt;br /&gt;
Function such as &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; preserves the length of list. But the notion of length does not appear explcitely in the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. This means that the current core termination prover often can not prove termination of a function that use &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. It also means that you need to give the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; to an external tool. &lt;br /&gt;
&lt;br /&gt;
We would like to automatically compute some concise information about the size differences between input and output of program. This means that we would like to infer (when possible) a notion of &#039;&#039;size&#039;&#039; from the definition of a function.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Remark&#039;&#039;&#039;: The halting problem is undecidable, the available external tools for checking termination are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the termination checker.&lt;br /&gt;
&lt;br /&gt;
====Task 3 - compilation ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Wojciech Matyjewicz, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.a - A first compiler using LLVM&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012) LLVM is a compiler infrastructure providing many tools: compilation strategy, virtual instruction set, compiler infrastructure, tools to write high level virtual machines, etc. LLVM is very attractive, because it is rather simple to use (it even has an OCaml interface) and can compile for a bytecode interpreter, can be used as a JIT compiler or a standard compiler. Moreover, it support a lot of platforms. It also provide some optimizations, which is important. We think that writing a compiler, with no optimization, for PML using LLVM should not be too hard (this is important that this task be easy, because this is not really research ...)&lt;br /&gt;
&lt;br /&gt;
A polish phd student Wojciech Matyjewicz has started to work on this in december. He visited the LAMA during one week to start the project. It is important to note that he is a first year phd in Poland and the first year there is equivalent to our Master 2. Which means that Wojciech Matyjewicz is a potential candidate.&lt;br /&gt;
&lt;br /&gt;
Then, we would like to improve our compiler in various direction. We mention here the ones that are innovative in this domain (we should also consider more standard optimization, but we do not mention them specifically). &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.b - Representation of cartesian product and disjoint sum&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012 for product) PML allows only one kind of cartesian product which in general (because of multiple inheritance and implicit subtyping) must be represented as a table (hash-table or maps based on binary search trees). These can impact performance. We plan to generate extra constraints for each occurrence of a constructor of a cartesian product in a program. Then, solving this constraint in a way that maximize speed (or size) should allow for a representation of cartesian product that is more efficient than using, for instance, OCaml. The same kind of optimization (with a different optimization criterion) should be done for sum types and the implementation of pattern matching. This optimisation should be included in the first compiler because the implentation with tables is too costly for a temporary solution.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.c - Unboxing&#039;&#039;&#039; (depends on some parts of 3.b, beginning 1/2012, delivered 1/2013) In general, 32 bits integer and floating point number are boxed (that is represented by a pointer). This allows a more elegant language. This can lead to major impact on performance especially when arrays are involved. We think that constraint-checking is a good framework to propagate type information and allow efficient unboxing. Nevertheless, doing enough unboxing to try to match the performance of low level languages like C is very hard. We hope that we can reuse some of the work of task 3.b, because unboxing can be seen also as the optimization of the representation of a cartesian product with only one field.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.d - compilation of affectation (reference and arrays) and IO&#039;&#039;&#039; (depend upon 1.c, beginning 09/2012, delivered 03/2014) After adapting uniqueness typing to PML (task 1.c), we will be able to compile affectation and IO imperatively as in any imperative programming language.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.e - Garbage collection&#039;&#039;&#039; (beginning 01/2014, delivered 09/2014) For simplicity reasons, the first compiler will simply use Boehm&#039;s garbage collector. This garbage collector is relatively efficient and simple to use. However, Boehm&#039;s GC isn&#039;t optimised for the kind of allocations used in a functional language. Moreover, having a multithreaded GC could prove usefull in moder environment. We thus plan to replace Boehm&#039;s GC by a dedicated GC tuned for our purposes.&lt;br /&gt;
&lt;br /&gt;
Writing a GC that is both efficient and correct is not easy, and this sub-task is rather orthogonal to the PML language, which explains why it only comes later during the project. Nevertheless, we feel it is necessary to go through the trouble if we want to be as efficient (or even better, more efficient) than existing functional languages...&lt;br /&gt;
&lt;br /&gt;
====Task 4 - Automated reasoning====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Frédéric Blanqui&lt;br /&gt;
&lt;br /&gt;
Participants: Frédéric Blanqui, Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
The kernel of the proof engine will be based on completion techniques. Knuth-Bendix completion tries to transform a set of unoriented equations into a set of (inter-reduced and) convergent, that is, terminating and confluent, set of rewrite rules. It can therefore be used for proving that some equality is the equational consequence of some equational theory. Indeed, when an equational theory can be completed into a convergent rewrite system, two terms are equivalent in this equational theory if their normal form in the convergent rewrite systems are equal.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.a - Adaptation of the Knuth-Bendix completion algorithm to PML&#039;&#039;&#039; (already started, delivered 09/2015) As explained just before, Knuth-Bendix completion is based on rewriting. However, in PML, programs are not rewriting systems. We therefore need to adapt Knuth-Bendix completion. We need both generalization, to use the notion of constructor present in ML and take care of the higher-order nature of ML (even if we can not hope much here).&lt;br /&gt;
As said above, something is already implemented, but it is trivial because completely restricted to closed terms. A first version should be able at least to rewrite a closed term modulo some simple equational (and universal) theory. An important point here is to ensure termination&lt;br /&gt;
of this algorithm and even a low complexity. The price to pay, will be incompleteness. A lot of care should also be devoted to the correctness of the implementation, because like for task 3.a, the consistency of PML relies on it.&lt;br /&gt;
&lt;br /&gt;
This task in one of the major task for PML and a first version already exists, but is non terminating in presence of equalities between functions: if we have an equation like &#039;&#039;f = f o f&#039;&#039;, PML may use this equation has a definition of &#039;&#039;f&#039;&#039; and loop. For dealing with these cases, we are considering a fix which involves some notions similar to those of &#039;&#039;geometry of interaction&#039;&#039;. Another particular and very important case of universal equation that we should take into account is associativity and commutativity. It is indeed very important to ease proofs on integers (addition and multiplication are associative and commutative). To this end, we could reuse the [http://cime.lri.fr CiME] library.&lt;br /&gt;
&lt;br /&gt;
Note that this work could benefit to other projects and tools, like [http://moca.inria.fr/ Moca], a generator of construction functions for private data types with algebraic invariants, also based on completion, or Europa, a proof assistant based on the lambda-pi-calculus modulo rewriting developed by Gilles Dowek and [http://www.lix.polytechnique.fr/Labo/Mathieu.Boespflug/ Mathieu Boespflug]. Indeed, currently, Moca generates OCaml code without guarantee on its correctness. Using PML instead, Moca could also generate a proof of the correctness of the generated construction functions.&lt;br /&gt;
Then, later, when trying to prove the correctness of a function defined on this private date type, one can use the invariants satisfied by the values of the private data type as assumptions, since these invariants are satisfied by construction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.b - Use of external provers&#039;&#039;&#039; (beginning 03/2012, delivered 09/2015) Like for termination proofs, in order to increase the proving capacities of PML, we will provide a translation of PML proof goals into the [http://www.cs.miami.edu/~tptp/ TPTP standard format] of the CASC competition in order to be able to use external provers too, and in particular provers based on completion like [http://www.waldmeister.org/ Waldmeister], [http://cime.lri.fr/ CiME] or [http://cl-informatik.uibk.ac.at/mkbtt/ mkbTT] but not only. And possibly some certifying provers like [http://focal.inria.fr/zenon/ Zenon] based on tableaux or [http://alt-ergo.lri.fr/ Alter-Ego] based on SMT (SAT solver modulo theory).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Same remark than for termination&#039;&#039;&#039;: The problem is undecidable, the available external tools for automated reasonning are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the automated reasonning.&lt;br /&gt;
&lt;br /&gt;
====Task 5 - validation (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Christophe Mouilleron, Tom Hirschowitz.&lt;br /&gt;
&lt;br /&gt;
The validation requires to write numerous examples to check that we fulfill our main goal, which is that all programs (with or without proof) are written in the best possible way. This work being research, we think that it is important that any piece of code written in PML that does not look &#039;&#039;right&#039;&#039; is carefully examined to check that this is not due to a defect in language design.&lt;br /&gt;
&lt;br /&gt;
Christophe Mouilleron and Erik Martin-Dorel started to work on the axiomatisation of computer arithmetics within an ongoing PEPS project. This is a good test for PML and moreover a requirement &lt;br /&gt;
because we want PML to be a real programming language and thefore the limited arithmetic of processors (32 and 64 bits integer and floating point number) must be supported by PML. However, proving software using them is not trivial at all and Christophe Mouilleron member of the Arénaire team in ENS Lyon is a specialist in this domain.&lt;br /&gt;
&lt;br /&gt;
Tom Hirshowitz and Christophe Raffalli already started (and almost finished) a proof in PML that &lt;br /&gt;
categories, functors and natural transformations form a 2-category (this development is available in the example directory in the current version of PML). We plan to continue such abstract developments and we think that they could lead to interesting perspectives about the modularity of PML.&lt;br /&gt;
&lt;br /&gt;
More general code, including a standard library and some significant mathematics should be developed (there is already around 10.000 lines of PML code in the current distribution). Moreover, we started to port to PML the course of software foundation written in Coq. The first three files are translated and there remain a dozen of files of around 2500 lines to translate. This is a major work, but would provide a very good test for PML, and a good tutorial.&lt;br /&gt;
&lt;br /&gt;
This task should deliver at least 100.000 lines of PML code to have&lt;br /&gt;
a sufficient corpus to say in which respect we fulfilled our goals.&lt;br /&gt;
&lt;br /&gt;
==== Task 6 - Optimisation of PML (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: C. Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: All (anyone could optimize the part of PML he was involved in).&lt;br /&gt;
&lt;br /&gt;
Some of the choice in the design of PML involve rather complex algorithm. Notably, this is the case of the constraint checking algorithm and completion procedure. The first implementation is not trivial but not optimized either. And very often, we have discoverd and will continue to discover that PML is too slow. This goal of this trasversal task is to ensure that PML is usable. &lt;br /&gt;
&lt;br /&gt;
Currently, some optimisations were already added. For instance, PML uses a sat solver for various &lt;br /&gt;
tasks: completeness and usefulness of cases in pattern matching and dealing with negative &lt;br /&gt;
hypothesis (like &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is not equal to &amp;lt;tt&amp;gt;S[x]&amp;lt;/tt&amp;gt;) in the completion procedure. Improving the sat solver using J.C. Filliâtre work [] and simploifying the formula before giving them to the sat solver were a major improvement.&lt;br /&gt;
&lt;br /&gt;
A lot of other optimisations are planned: &lt;br /&gt;
* The graph used to encode the typing constraints should probably be reduced (that is we should compute its transitive reduction). &lt;br /&gt;
* The completion procedure stores a set of terms of the language and we need a fast way to recover the set of all term using a given sub-term. The current implementation is too naïve. &lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
=== Planning of tasks, deliverables and milestones ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The following diagram represents the summary of the tasks and subtasks, together with the intended planning:&lt;br /&gt;
&lt;br /&gt;
[[Image:pml-gantt.png]]&lt;br /&gt;
&lt;br /&gt;
==Data management, data sharing, intellectual property and results exploitation==&lt;br /&gt;
&lt;br /&gt;
Results in each of the tasks will be published in journals (APAL, TCS, ...) and international conferences as usual (LICS, TLCA, CSL, CIE, ...).&lt;br /&gt;
&lt;br /&gt;
PML language is already distributed as open source software under the Cecill-B license. We think that for such a research platform, this is the only possible way to ensure that people will try it. As soon as a first compiler is available, we plan to produce easy-to-install packages, at least for some well-known Linux distributions (Debian and its derivatives seem a good choice).&lt;br /&gt;
&lt;br /&gt;
==Consortium organization and description==&lt;br /&gt;
&lt;br /&gt;
===Relevance of the partner for the project===&lt;br /&gt;
&lt;br /&gt;
This project involve only one partner, the LAMA (UMR 5127), where the coordinator of the project already developed the proof assistant PhoX. The main characteristic of PhoX is to be rather simple to use due to a set of tactics which is limited (less than 20 for the principal ones), but powerful. Moreover, tactics are extensible by &#039;&#039;incorporating theorems&#039;&#039; inside the tactics.&lt;br /&gt;
&lt;br /&gt;
Clearly, this means that efficiency was the main goal of PhoX. Unfortunately, like all tactical theorem prover, PhoX proofs are not readable. After a few attempts with a Mizar-like mode for PhoX, Christophe Raffalli decided to move to a new theorem prover, starting from scratch.&lt;br /&gt;
&lt;br /&gt;
Pierre Hyvernat is also in Chambery and the second developer of PML (he wrote the current termination checker). Tom Hirshowitz has some prior experience in his phd about the compilation of functional languages. At ENS Lyon, which is very near to Chambéry, Alexandre Miquel is a specialist of consistency proof for logical framework. Therefore, Chambery is the very natural partner for this project.&lt;br /&gt;
&lt;br /&gt;
===Qualification of the project coordinator and members===&lt;br /&gt;
&lt;br /&gt;
The coordinator and various members of the project comes from various horizon (see section 7), but they have a common background around the use and development of programming language and/or formal methods. We think that this variety, the small number of members, should allow for good communication and should be very fruitful. &lt;br /&gt;
&lt;br /&gt;
We think, that compared with the development of PML by Christophe Raffalli alone, such a team should speed up the development of PML approximately by a factor 3, making it possible to deliver a very innovative and useful tool at the end of the project. The lack of support for such a team would certainly limit the tool to an experimental toy with many development only partially (or even not at all) integrated in the project.&lt;br /&gt;
&lt;br /&gt;
Christophe Raffalli will also ask for delegations during the project to be able to spend even more time on it.&lt;br /&gt;
&lt;br /&gt;
==Scientific justification of requested budget==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Meetings (total 9720€ per year)====&lt;br /&gt;
 &lt;br /&gt;
Two meetings and one workshop per year, 3 days each, for 7 people. Each meeting costs&lt;br /&gt;
1 train ticket in France, 3 days and 2 nights:&lt;br /&gt;
3*7*(100 + 3*20 + 2*80) = 6720€. &lt;br /&gt;
&lt;br /&gt;
For the workshop, we have to invite 2 to 3 guests. Some may come from foreign country and we estimate the cost&lt;br /&gt;
to 3000€ per year. Which mean a total of 9720€ per year.&lt;br /&gt;
&lt;br /&gt;
====Visits (total 10000€)====&lt;br /&gt;
&lt;br /&gt;
We think that this is very important for this project to interact with other project.&lt;br /&gt;
For instance, Andreas Abel came to visit Chambéry in 2010 for two weeks financed by our PEPS&lt;br /&gt;
project and during this time induced an important bootstrap to the implementation of the termination checker &lt;br /&gt;
[Hyv10b] and contributed a non trivial example with a proved implentation of left-leaning red-black trees.&lt;br /&gt;
&lt;br /&gt;
We want to continue such interaction. Andreas Abel already agreed as well as Joe Wells for discusion about error reporting and , Assia Mahboubi for complex proofs involving the reflexion principle. Many other discussion would be profitable about PML runtime (with multithreading ?), interaction with external tools (termination checker or automated theorem prover), &lt;br /&gt;
uniqueness typing (meeting with people already using such technics), ...&lt;br /&gt;
&lt;br /&gt;
We plan around 4 short visits of one or two weeks from people outside the project to Chambéry and the same amount for short visit in the other direction. This means around 12 weeks per year with 8 travels for a cost of 500€ per week (x12) plus in average (depending if we use plane or train) the same amount for each travel (x8), with a total of 10000€ per year.&lt;br /&gt;
&lt;br /&gt;
====Conferences (total 9600€ per year)====&lt;br /&gt;
 &lt;br /&gt;
The members of the ANR will submit papers to international conferences and&lt;br /&gt;
journals and attend to specialized workshop. We have 2.5 person/year on the project with means &lt;br /&gt;
around 3 international conferences or workshop per year (estimated cost 2000€) and one national conference or workshop per year (estimated cost 1200€)&lt;br /&gt;
&lt;br /&gt;
====Master internships (total 1500€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We plan to host around four master internships in good conditions (possibly&lt;br /&gt;
followed by PhD studentships not financed by the ANR): one per year with a total cost of&lt;br /&gt;
6000€ (1500€ each: 300€ for travel and 200€ per month for an accommodation at&lt;br /&gt;
the CROUS).&lt;br /&gt;
&lt;br /&gt;
====Computers (total 2000€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We consider that the ANR project has to participate in the renewal of the&lt;br /&gt;
computers of its participants. The lifetime of a computer being 4 years and&lt;br /&gt;
the total number of month for permanent members of the project being 112, we&lt;br /&gt;
think that we should pay for 4 computers with an average value of 2000€ each&lt;br /&gt;
(we need powerful computers and laptops, because automated reasoning requires&lt;br /&gt;
a lot of computations and memory).&lt;br /&gt;
&lt;br /&gt;
====Human resources financed by the ANR (1 PhD student, 2 two years postdocs and 4 month of invited professor)====&lt;br /&gt;
 &lt;br /&gt;
This project involves many tasks and 7 members. However, all members&lt;br /&gt;
apart from the coordinator and Pierre Hyvernat can only devote 2-3 month per year to this project&lt;br /&gt;
(they are involved in other ongoing research). Although this is far from&lt;br /&gt;
negligible, we think that we will need more human power: we estimate that 1&lt;br /&gt;
PhD and 2 postdocs are reasonable. &lt;br /&gt;
&lt;br /&gt;
We also consider that one year post-doc are not sufficient, because the time need to &lt;br /&gt;
understand the existing code base is long and the student has both to write code and &lt;br /&gt;
publish its result. Moreover, the code produced by the student will not be an experimental&lt;br /&gt;
code to support its publication, but code which should remain in the project and be maintened by &lt;br /&gt;
other member of the project. In one year, this seems impossible to achieve.&lt;br /&gt;
&lt;br /&gt;
Moreover, as mentioned in the section about visits, we would like to have 1 month per year of invited professor.&lt;br /&gt;
&lt;br /&gt;
This would give a total 88 months (4 month invited, 36 for the PhD and 48 for the 2 postdocs)&lt;br /&gt;
To be compared with the total of 104/112 month not payed by the ANR. We consider that this is a good balance.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 308589€.&lt;br /&gt;
&lt;br /&gt;
====Human resources not financed by the ANR====&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! month/year&lt;br /&gt;
! percentage&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Raffalli&lt;br /&gt;
| 10&lt;br /&gt;
| 85%&lt;br /&gt;
|-&lt;br /&gt;
| Frédéric Blanqui&lt;br /&gt;
| 4&lt;br /&gt;
| 25%&lt;br /&gt;
|-&lt;br /&gt;
| Emmanuel Chailloux&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Tom Hirshowitz&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Pierre Hyvernat&lt;br /&gt;
| 6&lt;br /&gt;
| 50%&lt;br /&gt;
|-&lt;br /&gt;
| Alexandre Miquel&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Mouilleron&lt;br /&gt;
| 0/2&lt;br /&gt;
| 0/15%&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total per year&#039;&#039;&#039;&lt;br /&gt;
| 26/28&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total for 4 year&#039;&#039;&#039;&lt;br /&gt;
| 104/112&lt;br /&gt;
| &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Remark: the situation of Christophe Mouilleron is unknown next year. If it is possible he will &lt;br /&gt;
continue is work on PML started with the PEPS for around 2 month per year. But if it is not possible, &lt;br /&gt;
or if he is selected for the post-doc position, then we should not count it. We used the worst case&lt;br /&gt;
on the website.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 350333€ snas ternir compte de Christophe Mouilleron.&lt;br /&gt;
&lt;br /&gt;
==Annexes==&lt;br /&gt;
&lt;br /&gt;
===CV, Resume of all project members===&lt;br /&gt;
&lt;br /&gt;
==== Christophe Raffalli (project coordinator) ====&lt;br /&gt;
&lt;br /&gt;
Age 41, MCF at the LAMA (UMR 5127) since September 1997.&lt;br /&gt;
&lt;br /&gt;
After his PhD in Paris VII (defended in February 1994), Christophe Raffalli spent 1 and a half year at the LFCS in Edinburgh, 2 years at Chalmers university in Göteborg (post-doc of the TYPES European project) and 1 year as ATER in Créteil University.&lt;br /&gt;
&lt;br /&gt;
Research administration: For ten years, the LAMA was sub-site of the Paris VII site inside the TYPES project which was renewed several times and Christophe Raffalli was the coordinator for this sub-site. Currently the project is not financed by the E.U. Nevertheless, Christophe Raffalli is in charge of the organization of the next TYPES meeting in Aussois in May 2009.&lt;br /&gt;
&lt;br /&gt;
His research interests include:&lt;br /&gt;
&lt;br /&gt;
* theory and implementation of proof assistants,&lt;br /&gt;
* proof theory,&lt;br /&gt;
* implementation of programming languages (especially type-systems).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Raf10b] &#039;&#039;Realizability for programming languages&#039;&#039; (submitted, available as hal-00474043)&lt;br /&gt;
&lt;br /&gt;
* [Raf08a] &#039;&#039;PML and strong normalisation&#039;&#039; conference at the Types workshop, April 2008, Turino, Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf07b] &#039;&#039;PML: a new proof assistant&#039;&#039; conference at the Types workshop, may 2007, Cividale del Friuli (Udine), Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf06a] &#039;&#039;Realizability of the axiom of choice in HOL (An analysis of Krivines&#039;s work)&#039;&#039; with Frédéric Ruyer in Fundamenta Informaticae (2006)&lt;br /&gt;
&lt;br /&gt;
* [Raf05a] &#039;&#039;PhoX&#039;&#039; with Paul Rozière in The seventeen provers of the World, Freek Wiedijk (editor) LNAI 3600 pages 67-71&lt;br /&gt;
&lt;br /&gt;
* [Raf03b] &#039;&#039;System ST&#039;&#039; Schedae Informatica, proceedings of the Chambery-Krawow-Lyon Workshop, Vol. 12, pages 97-112 (June 2003)&lt;br /&gt;
&lt;br /&gt;
* [Raf02c] &#039;&#039;Getting results from programs extracted from classical proofs&#039;&#039;, TCS 2004, volume 323, pages 49-70&lt;br /&gt;
&lt;br /&gt;
* [Raf02b] &#039;&#039;System ST, beta-reduction and completeness&#039;&#039;, presented at LICS 2003, publication IEEE, pages 21-32&lt;br /&gt;
&lt;br /&gt;
* [Raf02a] &#039;&#039;Computer Assisted Teaching in Mathematics&#039;&#039;, with René David, to appear in the proceedings of the Workshop on 35 years of Automath (April 2002, Edingurgh)&lt;br /&gt;
&lt;br /&gt;
* [Raf01d] &#039;&#039;System ST, towards a Type System for Extraction and Proof of Programs&#039;&#039;, Archive for Pure and Applied Logic, 2003, volume 122, pages 107-130&lt;br /&gt;
&lt;br /&gt;
* [Raf01c] &#039;&#039;Apprentissage du raisonnement assité par ordinateur&#039;&#039;, avec René David, Quadrature numéro 45, printemps 2002, pages 25-36). Version courte parue dans la gazette de la SMF, avril 2002, numéro 92, pages 48-56&lt;br /&gt;
&lt;br /&gt;
==== Frederic Blanqui (INRIA, Rocquencourt) ====&lt;br /&gt;
&lt;br /&gt;
Age 38, permanent full-time researcher at [http://www.inria.fr INRIA].&lt;br /&gt;
&lt;br /&gt;
Frederic Blanqui is expert in the following areas:&lt;br /&gt;
* type theory,&lt;br /&gt;
* rewriting theory,&lt;br /&gt;
* termination,&lt;br /&gt;
* functional programming,&lt;br /&gt;
* proof assistants,&lt;br /&gt;
* and formal certification of program properties.&lt;br /&gt;
&lt;br /&gt;
Since September 2008, he is INRIA researcher at [http://liama.ia.ac.cn LIAMA], the Sino-French Laboratory in Computer Science, Automation and Applied Mathematics.&lt;br /&gt;
&lt;br /&gt;
Between 2003 and 2008, he was INRIA researcher at [http://www.loria.fr LORIA], Nancy, in the Protheo research team led by Pr Claude Kirchner, focusing on the use of rewriting techniques for programming, as well as specifying and proving program properties.&lt;br /&gt;
&lt;br /&gt;
Since 2004, he is leading the [http://color.inria.fr CoLoR] project which aims at providing tools for automatically certifying the termination of programs. Since 2007, CoLoR is the best certification back-end in the international [http://termination-portal.org/wiki/Termination_Competition competition on certified termination provers].&lt;br /&gt;
&lt;br /&gt;
In 2007 and 2008, he led the INRIA [http://quotient.loria.fr/ Quotient] project which aims at extending the [http://caml.inria.fr OCaml] programming language with types whose values automatically satisfy equational invariants using the [http://moca.inria.fr Moca] tool.&lt;br /&gt;
&lt;br /&gt;
He supervised 2 master thesis and 3 PhD students on the extension of type theory with decision procedures, the termination of typed higher-order rule-based programs, and the certification of termination proofs.&lt;br /&gt;
&lt;br /&gt;
He did his PhD with Pr Jean-Pierre Jouannaud at University Paris Sud between October 1998 and September 2001 on the combination of type theory and rewriting theory.&lt;br /&gt;
&lt;br /&gt;
Between October 2001 and August 2002, he worked on the certification of cryptographic protocols with Pr Larry Paulson at Cambridge, UK.&lt;br /&gt;
&lt;br /&gt;
Between September 2002 and September 2003, he worked at Ecole Polytechnique in the [http://coq.inria.fr Coq] development team on the extension of the proof assistant Coq with rewriting.&lt;br /&gt;
&lt;br /&gt;
More details on his activities and publications can be found on his [http://www-rocq.inria.fr/~blanqui/ web page] and in his [http://www-rocq.inria.fr/~blanqui/divers/cv.pdf CV].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
International journals with reading committee: 7&lt;br /&gt;
&lt;br /&gt;
International conferences with reading committee: 15&lt;br /&gt;
&lt;br /&gt;
Other publications (thesis, workshops, invited papers, reports, etc.): 15&lt;br /&gt;
&lt;br /&gt;
Prizes: 2001 [http://www.specif.org/ SPECIF] Award for his PhD thesis by the French national society of teachers and researchers in computer science; and 2001 Kleene Award for the best young researcher paper at the IEEE Symposium on Logic in Computer Science ([http://www2.informatik.hu-berlin.de/lics/ LICS]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Five most significant publications in the last 5 years:&lt;br /&gt;
&lt;br /&gt;
* [Bla11] F. Blanqui and A. Koprowski. &#039;&#039;CoLoR: a Coq library on well-founded rewrite relations and its application to the automated verification of termination certificates&#039;&#039;. To appear in Mathematical Structures in Computer Science.&lt;br /&gt;
&lt;br /&gt;
* [BRK10] F. Blanqui, C. Riba and C. Kirchner. &#039;&#039;On the confluence of lambda-calculus with conditional rewriting&#039;&#039;. Theoretical Computer Science 411(37), p. 3301-3327.&lt;br /&gt;
&lt;br /&gt;
* [BR09] F. Blanqui and C. Roux. &#039;&#039;On the relation between sized-types based termination and semantic labelling&#039;&#039;. CSL&#039;09. LNCS 5771.&lt;br /&gt;
&lt;br /&gt;
* [BJS08] F. Blanqui, J.-P. Jouannaud and P.-Y. Strub. &#039;&#039;From formal proofs to mathematical proofs: a safe, incremental way for building in first-order decision procedures&#039;&#039;. TCS&#039;08. IFIP 273.&lt;br /&gt;
&lt;br /&gt;
* [BHW07] F. Blanqui, Thérèse Hardin and Pierre Weis. &#039;&#039;On the Implementation of Construction Functions for Non-free Concrete Data Types&#039;&#039;. ESOP 2007: 95-109.&lt;br /&gt;
&lt;br /&gt;
==== Emmanuel Chailloux (LIP6, Paris) ====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Age 51,  full professor at the University &lt;br /&gt;
Pierre et Marie Curie ([http://www.upmc.fr UPMC - Paris 6]) in Paris France, &lt;br /&gt;
and since October 2006  researcher at the &lt;br /&gt;
[http://www.lip6.fr LIP6] computer science laboratory (UMR 7606), &lt;br /&gt;
in the &amp;quot;Algorithms, Programs and Resolution&amp;quot; team ([http://www-apr.lip6.fr APR]).&lt;br /&gt;
&lt;br /&gt;
His research work is related to design and implementation of programming languages : &lt;br /&gt;
* semantics, &lt;br /&gt;
* types systems, &lt;br /&gt;
* runtime implementation, &lt;br /&gt;
* multicores. &lt;br /&gt;
Most of the recent publications relate to safety-critical software development.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Recent publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[VWC-2011] Vaugon B., Wang P., Chailloux E. &#039;&#039; Les microcontrôleurs&lt;br /&gt;
PIC programmés en Objective Caml&#039;&#039;. Journées des Langages Applicatifs&lt;br /&gt;
(JFLA&#039;2011), janvier 2011.&lt;br /&gt;
&lt;br /&gt;
[WJC-2010] Wang P., Jonquet A., Chailloux E. &#039;&#039;Non-Intrusive&lt;br /&gt;
Structural Coverage for Objective Caml&#039;&#039;.  5th Workshop on Bytecode&lt;br /&gt;
Semantics, Verification, Analysis and Transformation (Bytecode), 2010.&lt;br /&gt;
&lt;br /&gt;
[PAMCCWMC-2009] Pagano B., Andrieu O., Moniot T., Canou B., Chailloux&lt;br /&gt;
E., Wang P., Manoury P., Colaço J.-L. &#039;&#039;Experience Report: Using&lt;br /&gt;
Objective Caml to develop safety-critical embedded tool in a&lt;br /&gt;
certificaiton framework&#039;&#039;.  International Conference of Functional&lt;br /&gt;
Programming (ICFP&#039;09), 2009.&lt;br /&gt;
&lt;br /&gt;
[CBC-2008] Canou B., Balat V., Chailloux E. &#039;&#039;O&#039;Browser : Objective&lt;br /&gt;
Caml on browsers&#039;&#039;. The 2008 ACM SIGPLAN Workshop on ML, 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;HIRONDML: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 2008, 55--69.&lt;br /&gt;
&lt;br /&gt;
[PACCCMW-2008] Pagano B., Andrieu O., Canou B., Chailloux E., Colaço J.-L., Moniot T., Wang P. &lt;br /&gt;
&#039;&#039;Certified development tools implementation in objective caml.&#039;&#039;  &lt;br /&gt;
International Symposium on Practical Aspects of Declarative Languages (PADL 08), 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;Hirondml: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 (2008) 55-69&lt;br /&gt;
&lt;br /&gt;
[HMC-2007] Henry G., Mauny M., Chailloux E. &#039;&#039;Typer la désérialisation&lt;br /&gt;
sans sérialiser les types&#039;&#039;. Technique et Science Informatiques 26, 9&lt;br /&gt;
(2007) 1067-1090.&lt;br /&gt;
&lt;br /&gt;
[CM-2006] Chailloux E., Mauny M. &#039;&#039;Programmation fonctionnelle&#039;&#039;.&lt;br /&gt;
Encyclopédie de l&#039;informatique et des systèmes d&#039;information (2006)&lt;br /&gt;
1016--1027.&lt;br /&gt;
&lt;br /&gt;
==== Tom Hirshowitz (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
34 ans, CR CNRS (informatique) , LAMA&lt;br /&gt;
&lt;br /&gt;
* 2007         CR CNRS au LAMA (UMR 5127) à Chambéry&lt;br /&gt;
* 2004-2007    CR CNRS au LIP (UMR5668) à Lyon&lt;br /&gt;
* 2003-2004    ATER, équipe Plume, LIP, ENS Lyon&lt;br /&gt;
* 2000-2003    Doctorat (dir.: X. Leroy, INRIA Rocquencourt, projet Cristal)&lt;br /&gt;
* 1999-2000    DEA à Paris 7&lt;br /&gt;
* 1996-2000    Ecole Nationale des Ponts et Chaussées&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;10 publications dans des revues et conférences internationales&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;publications choisies&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
# T. Hirschowitz, X. Leroy, and J. B. Wells. Compilation of extended recursion in call-by-value functional languages, PPDP 2003. Version journal dans Higher-Order and Symbolic Computation 22-1. 2009.&lt;br /&gt;
# R. Garner, T. Hirschowitz, and A. Pardon. Variable Binding, Symmetric Monoidal Closed Theories and Bigraphs. CONCUR&#039;09. 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. Contraction-free Proofs and Finitary Games for Linear Logic. MFPS, 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. A Theory for Game Theories. FSTTCS, 2007.&lt;br /&gt;
# T. Hirschowitz, X. Leroy. Mixin Modules in a Call-by-Value Setting, ESOP, 2002, journal version in ACM Transactions on Programming Languages and Systems, 2005.&lt;br /&gt;
&lt;br /&gt;
==== Pierre Hyvernat (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
Age 30, &amp;quot;maître de conférences&amp;quot; at the Université de Savoie (in Chambéry) since September 2006, member of the [http://www.lama.univ-savoie.fr LAMA].&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2005, under the supervision of Thierry Coquand (Chalmers, Göteborg, Sweden) and Thomas Ehrhard (at the time, IML, Luminy, Marseille, France)&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include&lt;br /&gt;
* denotational semantics,&lt;br /&gt;
* type theory and constructive mathematics.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Hyv10b] &#039;&#039;The Size-Change Termination Principle for Constructor Based Languages&#039;&#039; (hal-00547440, submitted)&lt;br /&gt;
&lt;br /&gt;
* [HHy06] with P. Hancock: &#039;&#039;Programming Interfaces and Basic Topology&#039;&#039;. &amp;quot;Annals of Pure and Applied Logic&amp;quot;, volume 137, January 2006,&lt;br /&gt;
&lt;br /&gt;
* [Hyv05] &#039;&#039;Synchronous Games, Simulations and lambda-calculus&#039;&#039;, proceedings of the &amp;quot;GaLoP&amp;quot; workshop, ETAPS 2005. (journal version submitted to Annals of Pure and Applied Logic),&lt;br /&gt;
&lt;br /&gt;
* [Hyv04] &#039;&#039;Predicate Transformers and Linear Logic: yet another Denotational Model&#039;&#039;, Lecture Notes in Computer Science, vol. 3210, September 2004.&lt;br /&gt;
&lt;br /&gt;
==== Alexandre Miquel (PPS, Paris 7) ====&lt;br /&gt;
&lt;br /&gt;
Age 37, &amp;quot;maître de conférences&amp;quot; at the Université Paris-Diderot (Paris 7) since September 2003, member of [http://www.pps.jussieu.fr/ PPS]. Currently CNRS research associate (&amp;quot;délégation&amp;quot;) in the Plume team at the LIP (ENS Lyon) since September 2008.&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2001, under the supervision of Hugo Herbelin (INRIA/LIX) in the Coq team (now TypiCal).&lt;br /&gt;
&lt;br /&gt;
From October 2001 to August 2002 he was postdoc in the Chalmers Institute of Technology (Göetborg, Sweden) under the supervision of Thierry Coquand, and from September 2002 to August 2003 he was &amp;quot;ATER&amp;quot; at the LRI (Orsay).&lt;br /&gt;
&lt;br /&gt;
He is a specialist of the models of type theory (especially the calculus of constructions) and of the correspondence between set theory and type theory. His research interests also include:&lt;br /&gt;
* logic, proof-theory, rewriting,&lt;br /&gt;
* denotational semantics (set- and domain-theoretic),&lt;br /&gt;
* realizability in classical logic.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
His most significant publications are:&lt;br /&gt;
&lt;br /&gt;
* [Miq07] &#039;&#039;Classical program extraction in the calculus of constructions&#039;&#039; (CSL&#039;07),&lt;br /&gt;
&lt;br /&gt;
* [Miq06] with A. Arbiser and A. Ríos. &#039;&#039;A lambda-calculus with constructors&#039;&#039; (RTA&#039;06),&lt;br /&gt;
&lt;br /&gt;
* [Miq04] &#039;&#039;Lambda-Z: Zermelo&#039;s Set Theory as a PTS with 4 Sorts&#039;&#039; (TYPES&#039;04),&lt;br /&gt;
&lt;br /&gt;
* [Miq03] &#039;&#039;A Strongly Normalising Curry-Howard Correspondence for IZF Set Theory&#039;&#039; (CSL&#039;03),&lt;br /&gt;
&lt;br /&gt;
* [Miq00] &#039;&#039;A Model for Impredicative Type Systems with Universes, Intersection Types and Subtyping&#039;&#039; (LICS&#039;00).&lt;br /&gt;
&lt;br /&gt;
==== Christophe Mouilleron (LIP, ENS de Lyon) ====&lt;br /&gt;
&lt;br /&gt;
Age 26, PhD student in the Arenaire team at the LIP (ENS de Lyon) since September 2008. He works under the supervision of Claude-Pierre Jeannerod (INRIA/LIP) and Gilles Villard (CNRS/LIP).&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include :&lt;br /&gt;
* computer arithmetic,&lt;br /&gt;
* code generation,&lt;br /&gt;
* formal proof of numerical properties in programs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [MouRev10] C. Mouilleron and G. Revy. &#039;&#039;Automatic Generation of Fast and Certified Code for Polynomial Evaluation.&#039;&#039; (submitted, available as ensl-00531721)&lt;br /&gt;
&lt;br /&gt;
* [JeaMou10] C.-P. Jeannerod and C. Mouilleron. &#039;&#039;Computing Specified Generators of Structured Matrix Inverses.&#039;&#039; (ISSAC&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [BJJK+10] C. Bertin, C.-P. Jeannerod, J. Jourdan-Lu, H. Knochel, C. Monat, C. Mouilleron, J.-M. Muller, and G. Revy. &#039;&#039;Techniques and tools for implementing IEEE 754 floating-point arithmetic on VLIW integer processors.&#039;&#039; (PASCO&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [LTdD+10] V. Lefèvre, P. Théveny, F. de Dinechin, C.-P. Jeannerod, C. Mouilleron, D. Pfannholzer, and N. Revol. &#039;&#039;LEMA : Towards a Language for Reliable Arithmetic.&#039;&#039; (PLMMS&#039;10)&lt;br /&gt;
&lt;br /&gt;
===Relevant publications by non participants to the project ===&lt;br /&gt;
&lt;br /&gt;
Here are some publication or resources of interest for the project:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Laguage design and theory:&#039;&#039;&#039;&lt;br /&gt;
* [SOW97] Martin Sulzmann, Martin Odersky, Martin Wehr, &#039;&#039;Type inference with constrained types&#039;&#039;, TAPOS, 1997.&lt;br /&gt;
* [HW04] Christian Haack and J. B. Wells, &#039;&#039;Type error slicing in implicitly typed higher-order languages&#039;&#039;, Sci. Comput. Programming, 50:189-224, 2004.&lt;br /&gt;
* [Ruy06] Frédéric Ruyer, &#039;&#039;Preuves, types et sous-type&#039;&#039;, phd 2006 directed by C. Raffalli.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Termination:&#039;&#039;&#039;&lt;br /&gt;
* [LJ01] Lee, Jones, et al. &#039;&#039;The size-change principle for program termination&#039;&#039; - ACM SIGPLAN Notices - 2001&lt;br /&gt;
* [Abel04] Andreas Abel, &#039;&#039;Termination Checking with Types&#039;&#039; ,Special Issue: Fixed Points in Computer Science (FICS&#039;03 and RAIR&#039;04)&lt;br /&gt;
* [Bar04]   G. Barthe, M. J. Frade  and E. Giménez, L. Pinto and T. Uustalu, &#039;&#039;Type-Based Termination of Recursive Definitions&#039;&#039;, 2004, Mathematical Structures in Computer Science.&lt;br /&gt;
* [Gie06] J. Giesl, S. Swiderski, P. Schneider-Kamp, and R. Thiemann &#039;&#039;Automated Termination Analysis for Haskell: From Term Rewriting to Programming Languages&#039;&#039;, Proceedings of the 17th International Conference on Rewriting Techniques and Applications (RTA-06), Lecture Notes in Computer Science 4098.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;the Clean language:&#039;&#039;&#039;&lt;br /&gt;
* [AGR92] Peter Achten, John van Groningen and Rinus Plasmeijer (1992). &#039;&#039;High-level specification of I/O in functional languages&#039;&#039;, Proc. of the Glasgow workshop on Functional programming, ed. J. Launchbury and P. Sansom, Ayr, Scotland, Springer-Verlag, Workshops in Computing, pp. 1-17.&lt;br /&gt;
* [AcP95] Peter Achten and Rinus Plasmeijer (1995). &#039;&#039;The Ins and Outs of CONCURRENT CLEAN I/O&#039;&#039;, Journal of Functional Programming, 5, 1, pp. 81-110.&lt;br /&gt;
* [AcP97] Peter Achten and Rinus Plasmeijer (1997). &#039;&#039;Interactive Functional Objects in CLEAN&#039;&#039;, Proc. of the 1997 Workshop on the Implementation of Functional Languages (IFL&#039;97), ed. K. Hammond Davie, T., and Clack, C., St.Andrews, Scotland,&lt;br /&gt;
* [VPA07] Edsko de Vries, Rinus Plasmeijer, and David M. Abrahamson, &#039;&#039;Uniqueness Typing Simplified, by Edsko de Vries&#039;&#039;,&lt;br /&gt;
* [http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf the language report] by Rinus Plasmeijer and Marko van Eekelen,&lt;br /&gt;
* [http://clean.cs.ru.nl/ the language homepage].&lt;br /&gt;
&lt;br /&gt;
===Involvement of project participants to other grants, contracts, etc …===&lt;br /&gt;
&lt;br /&gt;
* Frederic Blanqui is involved in the Sino-French ANR SIVES 2009-2011 on SImulation and Verification based platform for developing Embedded Systems.&lt;br /&gt;
* Emmanuel Chailloux is member of the ANR PWD (&amp;quot;Programmation du Web Diffus&amp;quot;), whose leader is Manuel Serrano (Inria), and the FUI [http://opengpu.net/ OpenGPU project].  &lt;br /&gt;
* Tom Hishowitz is involved in the ANR PiCoq the ANR proposals RÉCRÉ and CATHRE.&lt;br /&gt;
* Pierre Hyvernat is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Alexandre Miquel is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Christophe Raffalli is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Remark: the interaction with PML and RÉCRÉ is natural because the proof technics used for ensuring some of the properties of the language PML is réalizability which is one of the théma of the ANR proposal RÉCRÉ.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5076</id>
		<title>ANR PML</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5076"/>
		<updated>2011-01-13T11:08:38Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Task 5 - validation (transverse task) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;URL of PML project: &amp;lt;tt&amp;gt;http://lama.univ-savoie.fr/tracpml&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Context and positioning of the proposal==&lt;br /&gt;
&lt;br /&gt;
Ever since FORTRAN appeared fifty years ago, programming languages have been evolving rapidly. These languages now include more and more sophisticated concepts like &amp;quot;objects&amp;quot;, &amp;quot;type inference&amp;quot;, &amp;quot;modules&amp;quot;... However, this richness is also what makes it more and more complex to train programmers and makes it difficult for them to keep up with the innovations and changes in programming languages.&lt;br /&gt;
&lt;br /&gt;
Another orthogonal phenomenon is the emergence of formal methods used in conjunction with various programming languages to test, check or prove software. This introduces another layer to languages in order to write specifications, and sometimes yet another one for proofs. Learning a programming language together with the associated specification/proof languages can take an important effort.&lt;br /&gt;
&lt;br /&gt;
Projects such as [http://www.cs.utexas.edu/users/moore/acl2/ ACL2], the successor of  [http://www.cs.utexas.edu/users/boyer/ftp/nqthm nqthm, the Boyer-Moore theorem prover] uses a rather simple language (namely LISP) both as a programming language and specification language, allowing to keep a unity in the system. Unfortunately, LISP is somewhat limited both as a programming language (no good treatment of sum type, no module system) and a specification language (very limited quantification). Moreover, LISP has no compile-time type-checking, which has proved very useful to detect bugs and automatically assert properties.&lt;br /&gt;
&lt;br /&gt;
The aim of this project is to build a very powerful language (with no loss of expressive power compared to state of the art languages) based on a very small number of simple features. We think this will be possible thanks to recent progress both in the semantics of programming languages and the apparition of new algorithms for type inference based on constraints-solving. In fact, we propose in [RAF10b] an innovative concept derived from the later to enable this: constraints-checking.&lt;br /&gt;
&lt;br /&gt;
Moreover, the language will be used not only as a programming language and a specification language (like in ACL2), but also as the proof language. This is natural for an ML-like language because pattern-matching is a natural and powerful way to make a proof by case analysis. This also means that our tool will follow the &#039;&#039;KISS&#039;&#039; philosophy: relatively few (unified) features, yet powerful.&lt;br /&gt;
&lt;br /&gt;
The idea of a new language arose from the discovery of a new typing algorithm [RAF10b] whose implementation gave birth to a first implementation of PML (Proved ML) by Christophe Raffalli. This implementation is already available from [http://www.lama.univ-savoie.fr/~pml the web page of the language]. However, turning PML into a real tool requires a lot of research and implementation work and this is why we request the help of the ANR. Some of the goals are highlighted in the next sections.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML aproach to proofs of specification is unique&#039;&#039;&#039; PML has no dedicated proof language, but the user can still write proofs! Existing programming languages supporting specifications use two alternatives: automated proofs (ACL2, Why) or proof obligations that the user can prove using specific language (Coq extraction, Focalize, Why). Several systems provide both, the manual proofs being used only when automation fails. PML is very different in spirit: it introduces a new instruction, written with a &amp;quot;scissors symbol&amp;quot; &amp;lt;tt&amp;gt;&#039;&#039;&#039;8&amp;lt;&#039;&#039;&#039;&amp;lt;/tt&amp;gt; to express that the corresponding position in the program is &#039;&#039;dead&#039;&#039;, meaning that it can not be reached during evaluation. This condition is checked by a terminating variant of the Knuth-Bendix completion algorithm. This is rather simple and therefore easier to trust than modern decision procedures. However, it only solves trivial cases: to write complex proofs, the user just uses the same syntax as for programs to do case analysis or induction (&#039;&#039;ie.&#039;&#039; recursive definitions). This means that the user does not need learn a specific proof language and hopefuly implies that PML is easier to learn and probably more adapted to industry that previous solutions.&lt;br /&gt;
&lt;br /&gt;
The logic of PML is just the equational theory of its programming language; and we use variants of Knuth-Bendix completion as a proof-checker. The first experiments with the current implementation are promising. However, Knuth-Bendix procedure in the context of ML is a complex and new research problem. A lot more work is needed, for instance to handle proofs in arithmetic which occur quite often. Here is an example of a proof in arithmetic, checked in the current version of PML. This is not completely satisfactory (hard to write), but shows the use of the language for both proofs and programs and the use of recursive functions for inductive proofs:&lt;br /&gt;
&lt;br /&gt;
  val rec mul_associative x y z |- (x * y) * z == x * (y * z)&lt;br /&gt;
    proof match x with&lt;br /&gt;
      Z[] -&amp;gt; 8&amp;lt; (* trivial case handled automatically by Knuth-Bendix *)&lt;br /&gt;
    | S[x&#039;] -&amp;gt;&lt;br /&gt;
      let _ = mul_associative x&#039; y z in (* There is a syntactic sugar for that... *)&lt;br /&gt;
        (* this adds the fact that (x&#039;*y) * z == x&#039; * (y*z) to the environment *)&lt;br /&gt;
 &lt;br /&gt;
      let _ = mul_right_distributive y (x&#039; * y) z in&lt;br /&gt;
        (* this adds the fact that (y + x&#039;*y) * z == y*z + (x&#039;*y)*z *)&lt;br /&gt;
 &lt;br /&gt;
        (* the environment now contains enough information for Knuth Bendix to handle the rest:&lt;br /&gt;
         *    - x*(y*z)  ==  y*z + x&#039;*(y*z)  : by definition&lt;br /&gt;
         *    - x*y == y + x&#039;*y : by definition&lt;br /&gt;
         *      and so (x*y)*z == (y + x&#039;*z)*z&lt;br /&gt;
         *    - (x&#039;*y) * z == x&#039; * (y*z)  :  by the recursive call to mul_associative&lt;br /&gt;
         *    - (y + x&#039;*y) * z == y*z + (x&#039;*y)*z : by the call to mul_right_distributive  *)&lt;br /&gt;
      8&amp;lt;&lt;br /&gt;
&lt;br /&gt;
Moreover, this style of proof is declarative and relatively readable (like Mizar proofs) while concise at the same time. This is very important when you want to maintain large developments.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;PML is different from the other modern programming languages&#039;&#039;&#039; because its design focuses on a few powerful concepts. One consequence is that it is more difficult for a compiler to produce efficient code. In particular, since PML unifies several notions of products (modules, tuples and records), there is no simple way to choose the internal representation of a product, especially with implicit subtyping. Writing a good compiler for PML will thus require more complex and original optimization schemes (probably driven by typing) than languages like OCaml or Haskell. A Polish student (Wojciech Matyjewicz) is just starting a PhD on this very topic.&lt;br /&gt;
&lt;br /&gt;
Here is a simple example, accepted by the current version of PML, demonstrating product type, sum type and subtyping. We define ternary trees as an extension of binary trees with an implicit subtyping&lt;br /&gt;
relation (all functions accepting binary_trees will accept ternary trees, by ignoring the &amp;lt;tt&amp;gt;middle_son&amp;lt;/tt&amp;gt;):&lt;br /&gt;
&lt;br /&gt;
 type rec binary_tree (A) =&lt;br /&gt;
   [ Nil[] | Node[A with left_son : binary_tree(A); right_son : binary_tree(A)] ; ]&lt;br /&gt;
 type rec ternary_tree(A) =&lt;br /&gt;
   binary_tree({ A with middle_son : ternary_tree(A) ;})&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML requires a termination criterion&#039;&#039;&#039; because a proof by induction will just be a normal recursive program. Such a program has to be well-founded in order to correspond to a valid proof. A subset of Haskell can now use the Aprove tool to establish termination for simple programs. However, we want the test to be fully integrated with the language, and be compatible with very modular programs. At the moment, these goals seem difficult to achieve with Aprove or other external termination checkers. A first termination criterion based on Lee, Jones &amp;amp; Ben-Amram&#039;s &amp;quot;size-change termination principle&amp;quot; was implemented by Pierre Hyvernat [Hyv10b]. While this test is quite powerful, it is necessarily incomplete, and quite some work is required to make termination proofs of complex programs tractable.&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical description==&lt;br /&gt;
&lt;br /&gt;
===Background, state of the art===&lt;br /&gt;
&lt;br /&gt;
====Programming language====&lt;br /&gt;
&lt;br /&gt;
The ML programming language, created by Robin Milner &amp;lt;em&amp;gt;et al&amp;lt;/em&amp;gt; in the 80&#039;s has two major distinctive features:&lt;br /&gt;
* Algebraic data-types and pattern matching: data types are basically all constructed using fixpoint, cartesian product (product types) and disjoint union (sum types).&lt;br /&gt;
* Static type inference: the type of every piece of code is automatically inferred using Hindley-Milner algorithm (HM). By by construction, once compiled, an ML program can not crash (no segmentation fault). More precisely, when we do not use unsafe features of the language (like interface with unsafe libraries written in C), if an ML program produces a segmentation fault, then there is a bug in the type-checker or the compiler.&lt;br /&gt;
&lt;br /&gt;
Recent progress in type inference algorithm uses constraint solving. This means that the type system can be described in first-order predicate logic in such a way that a type inference problem is a formula written in a decidable fragment of first-order predicate logic (often the purely existential fragment). Hence, any constraint solver can be turned into a type-checker for ML. These approach is known as HM(X) (see [SOW97]).&lt;br /&gt;
&lt;br /&gt;
There are two problems with this approach:&lt;br /&gt;
* The complexity of constraint solving can be too high for practical use, especially when using a general purpose constraint solver. To our knowledge, there are currently no mainstream implementation of ML based on HM(X).&lt;br /&gt;
* HM(X) does not completely solve the problem of subtyping. The language to express the types constructed by the constraint solver is the same as the language of types used by programmers. With constraints &amp;lt;math&amp;gt;\alpha \subseteq \beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\alpha \subseteq \gamma&amp;lt;/math&amp;gt; for three types &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\gamma&amp;lt;/math&amp;gt;, the most natural solution is &amp;lt;math&amp;gt;\alpha = \beta \cap \gamma&amp;lt;/math&amp;gt;. This implies that intersection needs to be part of the language for types. This means that constraints such as &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \delta&amp;lt;/math&amp;gt; may also appear and they are problematic to deal with. Similar reasoning shows that constraints of the form &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \beta&#039; \cup \gamma&#039;&amp;lt;/math&amp;gt; may appear, increasing the complexity of constraint solving by an exponential factor.&lt;br /&gt;
&lt;br /&gt;
PML&#039;s approach is to replace type-inference by &#039;&#039;constraint &amp;lt;u&amp;gt;checking&amp;lt;/u&amp;gt;&#039;&#039; rather than constraint solving: we only check that the constraints are satisfiyable in some model. Type-checking in the current implementation of PML can be seen as a black box ensuring that nothing can go wrong during execution. Moreover, since we do not need to write solutions for the constraints, the language for types can be relatively simple. In fact, the types written by the programmer aren&#039;t even the actual type constraints that are checked: they are syntactic sugar for the projection operator onto the intended type (giving for free nice feature like higher-order parametric types, that is types with parameters which may be themselves types with parameters). In other words, the expression &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; is a synonym for &amp;lt;tt&amp;gt;(id_nat x)&amp;lt;/tt&amp;gt; where&lt;br /&gt;
  val rec id_nat x = match x with&lt;br /&gt;
      Z[] -&amp;gt; Z[]&lt;br /&gt;
    | S[x&#039;] -&amp;gt; S[id_nat x&#039;]&lt;br /&gt;
is defined internally by PML. The constraint generated by &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; mean exactly that &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is of type &amp;lt;tt&amp;gt;nat&amp;lt;/tt&amp;gt;...&lt;br /&gt;
&lt;br /&gt;
With this approach, we loose type-inference and the ability to display types in error messages. Nevertheless, PML error reporting is quite helpful because, in case of problem, it displays three positions in the code and an error message like this &amp;lt;tt&amp;gt;error at position 1, label &amp;quot;id&amp;quot; projected at position 2 do not appear in the value constructed at position 3&amp;lt;/tt&amp;gt;. This kind of error message is in fact of bounded length and often more useful than OCaml or SML messages. We can understand this as showing three points in the &#039;&#039;slice&#039;&#039; of the error, as introduced by Joe Wells in [HW04].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Proof assistant====&lt;br /&gt;
&lt;br /&gt;
Proof assistants have evolved rapidly since Automath in the 70th. Two main trends coexist: automated proof assistants such as ACL2, PVS and &#039;&#039;safe&#039;&#039; ones such as Coq, Isabelle, PhoX, Lego, HOL, Matita, &amp;lt;em&amp;gt;etc.&amp;lt;/em&amp;gt; The former incorporate very sophisticated automated deduction strategies, with no &#039;&#039;certificate&#039;&#039; for the validity of the proof, while the later require all proofs to be done in a specific framework (like natural deduction or type theory) allowing for a simple check of the proof. The gap between the two approaches tend to be reduced by the emergence of complex tactics (for Coq or Isabelle mainly) which build proofs for the user. For instance Zenon is an advanced automated first-order theorem prover outputing a Coq proof.&lt;br /&gt;
&lt;br /&gt;
The common defect of all these proof assistants is that a proof can not be written nor understood without running the proof assistant. Some proof assistants such as Mizar or Alf do not follow exactly the above scheme: Mizar has a declarative style for proof which is (in theory) readable by a human and checked by a limited checker. (This proof style has been adapted to Coq and Isabelle.) Unfortunately, there is no formal description of the Mizar proof checker. Alf on the other hand is based on proof theory and requires the user to basically write the complete proof tree just leaving out a few details. The logic is very well formalized and simple, but writing proof is tedious and not similar to the usual practice of informal mathematics.&lt;br /&gt;
&lt;br /&gt;
This picture of the world of proof assistants shows that some fundamental work is needed. In the current version of PML, the logic is just an equational theory of the underlying programming language. This is easily described formally. The proof engine is, like in Mizar, a limited automated checker inspired by the Knuth-Bendix completion algorithm (KB). The completion algorithm used in PML had to be adapted to the higher-order constructs of ML-like languages and restricted to ensure termination and an acceptable complexity. The current limitation is probably too strong: it is limited to closed terms and cannot use universal theorems automatically (as in the first example of section 1, where one has to give explicitly the argument to use distributivity).&lt;br /&gt;
&lt;br /&gt;
Nevertheless, preliminary examples in the current version shows that the approach is worth trying: proofs are concise and readable once you know the language. A very encouraging point is that all examples where written without interface. This really means that proofs are readable without the help of a computer.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Rationale highlighting the originality and novelty of the proposal===&lt;br /&gt;
&lt;br /&gt;
The final objective of our project would be a full PML compiler, bootstrapped and completely proved with itself (full bootstrap). This does not exist for any language and is far too ambitious for a four years project.  More realistically, we plan to produce a compiler for PML, written in PML, but not proved in PML yet.&lt;br /&gt;
&lt;br /&gt;
We also want to develop proof-checking in such a way as to allow very elegant proofs, supporting the feasibility of a full bootstrap by various examples, some of them being near to industrial application, some others being algorithms coming from implementation of programming languages.&lt;br /&gt;
&lt;br /&gt;
We have focused the existing development on the quality of the language both for proofs and programs. By quality, we mean easy to understand and write (and therefore, easy to learn). We think that using the programming language as a proof language could make formal methods more attractive to the industry without the defect of systems like PVS and ACL2 where the automated tactics replace the need for a proof language, but are sometimes hard to control and use. For instance, finding the right &#039;&#039;lemmas&#039;&#039; to make a proof possible in ACL2 is quite difficult.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other proof systems devoted to programming.&#039;&#039;&#039; Many other proof systems have been used or specifically developed&lt;br /&gt;
to allow the production of certified code: extraction in Coq, Why with its automated prover Who from the Proval project, Focalize, PVS, ATS, ... None of these system uses the programming language as a proof language. They all have a dedicated language for proofs and even if some of them like Focalize or Coq extraction using a Mizar style mode for proof, have readable proofs, learning the proof language is never trivial. Other systems like PVS, ATS, Why using Who rely on automated deduction. In those cases, the behavior of the automated prover is always hard to predict.&lt;br /&gt;
&lt;br /&gt;
Another selling point is that the logic and programming language are fully integrated. This is not a two level systems like most systems (but not all, ACL2 for instance is fully integrated). In PML, the statements of theorems and their proofs are expressions at the same level than programs. This means that a program can contain specifications that contains program definitions in their statement or proof and so on. This is generally not possible (even in ACL2) and makes it possible to write modules with their specifications.&lt;br /&gt;
&lt;br /&gt;
On of the key idea for this project is that any ML-like programming language has all the features needed for a proof language: case analysis via pattern matching and exception handling, induction, calling previously defined program/theorems. This means that it is natural to explore this direction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other programming languages&#039;&#039;&#039;. Another key idea in PML is to develop the language and its proof-checker together. This has a great impact on the design of PML. Let&#039;s illustrate this with a concrete example: exception handling. In ML, there is a&lt;br /&gt;
  try P with e -&amp;gt; R&lt;br /&gt;
but, this is not sufficient to do case analysis on the fact that a program &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises or not an exception. In particular, &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; can be the proof just in case &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises an exception. However there is no place holder for the normal case (without exception). This is why we had to introduce a&lt;br /&gt;
  let try x = P in Q with e -&amp;gt; R&lt;br /&gt;
where &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; is evaluated only when &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; reduces to a value.&lt;br /&gt;
&lt;br /&gt;
A great number of decisions on the language design comes from the interaction between the development of the programming language and its proof-checker. Another key feature of PML, which makes the project original even as a programming language compared to many other projects of programming language research (GALLIUM, Haskell, Scala, ...) is the use of constraint checking. This choice arises from the fact that we want a language as small as possible, because a proof-checker is complex and therefore, we want to fully unify all sorts of Cartesian product including modules, records, tuples and variant with multiple argument. This is already achieved in the current implementation of PML and to my knowledge, no ML like language have a unique but still powerful notion of Cartesian product.&lt;br /&gt;
&lt;br /&gt;
All the systems previously mentioned allow to prove programs in limited subsets of existing languages like ML or Haskell. The prover has to find ways to deal with those languages&#039; defects rather than improve them...&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical program, project management==&lt;br /&gt;
&lt;br /&gt;
===Specific aims of the proposal===&lt;br /&gt;
&lt;br /&gt;
As said in the previous section, the final objective would be to have a fully bootstrapped PML language: this would mean that PML is entirely written and proved in PML. This would be too ambitious at first, and we chose to focus here on the design of the language plus a proof of concept, that is compilation and proof of various examples, searching to do our best on the following points:&lt;br /&gt;
&lt;br /&gt;
* Natural way of writing programs (Task 1)&lt;br /&gt;
* Efficiency of the code generated by the compiler, despite the heavily use of subtyping (Task 3)&lt;br /&gt;
* Readable and short proofs (Task 1, Task 4)&lt;br /&gt;
* Efficiency of type-checking and compilation (Task 2 and 6)&lt;br /&gt;
* Efficiency of proof-checking (Task 4 and 6)&lt;br /&gt;
* All of the above points need testing, and we created a transverse fifth task for that.&lt;br /&gt;
&lt;br /&gt;
===Project management===&lt;br /&gt;
&lt;br /&gt;
We plan to have one 3 days workshop per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems. We already have the agreement of some people to participate in such meetings: Joe Wells, Assia Mahbouby, Andreas Abel, ...&lt;br /&gt;
We plan to have one 3 days meetings per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We will also organize two project meeting per year, just to keep track of progress, share idea and organize the above workshop and other invitation.&lt;br /&gt;
&lt;br /&gt;
We want also to organize visits of one or two members of the project to visit researcher on similar topic (typically a member of the project could visit one of the invited speaker of our workshop). Members of the project should also travel to conference on the subject like POPL, LICS, CSL, TYPES or the recently created CPP (first conference in 2011).&lt;br /&gt;
&lt;br /&gt;
===Detailed description of the work organized by tasks===&lt;br /&gt;
&lt;br /&gt;
====Task 1 - theoretical work, design of the language ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Alexandre Miquel, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.a - Correctness of the constraint checking algorithm&#039;&#039;&#039; (delivered&lt;br /&gt;
09/2012): [RAF10b] already cover the correctness without polymorphism. A draft version of &lt;br /&gt;
the correctness proof with polymorphism does exist but needs more work. The &lt;br /&gt;
main open problem here is the interaction with the termination-check. The current work &lt;br /&gt;
proves that when constraints are checked, the program can only loop via recursive definitions.&lt;br /&gt;
Then, we would like to prove that the program is terminating if recursive definitions are accepted by the &lt;br /&gt;
termination checker. However, this is non trivial.&lt;br /&gt;
&lt;br /&gt;
This being a central piece of PML, it should be also one&lt;br /&gt;
of the first tests for PML in task 5. We could also prove this part of PML in&lt;br /&gt;
Coq (in fact 2 provers proving themselves and each other correct is a much&lt;br /&gt;
stronger warranty than one prover proving itself).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.b - Consistency of proof-checking&#039;&#039;&#039; (beginning 09/2011, delivered before 09/2013 for the core of the language): This is essential for clearly defining the logic of PML and prove its consistency. This should not be too hard for the core of the language. However, this proof has to be extended to take into account all future extensions of the language and could be seen as a &#039;&#039;permanent task&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.c - Adaptation of uniqueness typing to the context of constraint checking&#039;&#039;&#039; (beginning 09/2012, delivered 01/2014): The current version of PML is a pure functional programming language, with no imperative feature. This is problematic, because input/output is necessary for real programs and affectations are required for efficiency especially when using large arrays. We plan to adapt the approach of the [http://clean.cs.ru.nl/ Clean language] [AGR92], [AcP95], [AcP97], [VPA07]. In Clean, all programs can be analyzed as purely functional programs, but the type system can check that some data are not used any more and reuse the place in memory for other data (allowing affectation). For instance, in such a context writing in a file &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; can be written as &amp;lt;tt&amp;gt;let f&#039; = write f str in ...&amp;lt;/tt&amp;gt;, but the compiler must check that &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; will not be used anymore implying the equivalence between the standard imperative semantics of writing to file and the purely functional semantics used by proofs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.d - Private, abstract and existential types.&#039;&#039;&#039; (beginning 09/2011, delivered&lt;br /&gt;
09/2012 for private type, beginning 09/2012, delivered&lt;br /&gt;
09/2013 for existential types and beginning 09/2013, delivered 09/2015 for abstract&lt;br /&gt;
types)&lt;br /&gt;
 &lt;br /&gt;
Abstract data types hide the definition of a data type and allow the user of&lt;br /&gt;
a library to be sure that his code will continue to work even if the internal&lt;br /&gt;
representation of data are changed. In the context of constraint-checking in&lt;br /&gt;
PML, adding abstract data types seems to be a challenging task. Moreover,&lt;br /&gt;
abstract data-types are a form of existential quantification over types and&lt;br /&gt;
could raise some consistency issues. We hope to find a way to incorporate&lt;br /&gt;
abstract types in PML without loosing coherence.&lt;br /&gt;
 &lt;br /&gt;
A first step would be private data types. They are a very simple yet very powerful mechanism for easily&lt;br /&gt;
ensuring invariants on all values of a data type. This mechanism is as&lt;br /&gt;
follows: the compiler simply checks that the constructors of a data type are&lt;br /&gt;
not used for constructing values. Values are constructed by using construction&lt;br /&gt;
functions, like with abstract data types. However, unlike with abstract data&lt;br /&gt;
types, constructors can still be used as patterns for defining functions by&lt;br /&gt;
pattern-matching. Hence, a library on a private data type is not closed but&lt;br /&gt;
can be extended easily. Private data types are therefore an important and very&lt;br /&gt;
useful feature for defining data structures with complex invariants and&lt;br /&gt;
proving their correctness more easily. They have been implemented in OCaml by&lt;br /&gt;
Pierre Weis and are described in Frédéric Blanqui, Thérèse Hardin and Pierre&lt;br /&gt;
Weis&#039; ESOP&#039;07 paper [BHW07].&lt;br /&gt;
&lt;br /&gt;
A second step would be existential types, which are very similar to abstract types,&lt;br /&gt;
but with no free name for the abstract type. On a logical level, they do imply an existential quantification over types&lt;br /&gt;
which has to be limited to ensure consistency. However existential types do not require the type to have a free name, which corresponds in logic to a definite description operator (similar to Hilbert&#039;s epsilon operator), and this, being connected to the axiom of choice (over types), may be really problematic for consistency. Some work related to this exists in the phd thesis of F. Ruyer, a former student of C. Raffalli [Ruy06].&lt;br /&gt;
&lt;br /&gt;
====Task 2 - termination====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Pierre Hyvernat&lt;br /&gt;
&lt;br /&gt;
Participants: Christophe Raffalli, Andreas Abel, Frederic Blanqui&lt;br /&gt;
&lt;br /&gt;
Remark: this is an essential task, running during the 4 years. There will always be some embarrassing examples that do not work, but could work... both for the core and auxiliary criterion (see below for the distinction) meaning that this research field will remain open forever.&lt;br /&gt;
&lt;br /&gt;
Even if it might be counter-intuitive at first, it is often necessary to write programs whose execution can be infinite. For example, any kind of &amp;quot;server&amp;quot;, or almost any interactive program might have infinite executions. Even in purely mathematical setting, it can be interesting to have intermediary non-terminating functions. Consider a function outputting the stream of prime numbers : even if this function is non-terminating, we might use it in a terminating manner in a proof by requesting the &#039;&#039;n&#039;&#039; first prime numbers.&lt;br /&gt;
&lt;br /&gt;
Since PML uses full recursion (keyword &amp;lt;tt&amp;gt;rec&amp;lt;/tt&amp;gt;), writing such programs is easy. On the other hand, the notion of &amp;quot;terminating&amp;quot;, or &amp;quot;well-founded&amp;quot; recursive function isn&#039;t part of the core of PML: such programs are just special cases of recursive programs. The user will have to specify which functions are in fact terminating and might have to prove it himself when PML cannot infer termination automatically.&lt;br /&gt;
&lt;br /&gt;
Proofs of specifications are just PML programs, and those cannot be allowed to run infinitely. More precisely, even if proof will never be run at all (no computational content), they are required to be well-founded. The consistency of PML relies on this. In order to relieve the user from proving that all proofs are in fact terminating, PML should offer a way to check automatically that (some) functions are terminating. Because the halting problem is undecidable, it is hopeless to do that in all generality, but this is seldom necessary: many proofs terminate for obvious reasons. PML should only work for most of the functions, most of the time (rather than work for all the functions, all the time...)&lt;br /&gt;
&lt;br /&gt;
Technically speaking, PML can infer an error called &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; when it encounters a program which, it thinks, may not terminate. Such an error cannot be captured: this is an error rather than an exception. The property we need to guarantee is that if PML doesn&#039;t infer the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; possible, then the program in question does indeed terminate. If the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; is possible for a terminating function, the user can still provide PML with a proof that this error is never raised. PML current syntax for that is &amp;lt;tt&amp;gt;[p proof ... ]&amp;lt;/tt&amp;gt; where &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; is a term and &amp;lt;tt&amp;gt;...&amp;lt;/tt&amp;gt; is a proof that &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; doesn&#039;t raise any exception nor error (this is the desired property for proofs).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.a - Core termination criterion&#039;&#039;&#039; (delivered 09/2010)&lt;br /&gt;
&lt;br /&gt;
This first test is now part of PML. Since primitive recursive function isn&#039;t enough in practice, even for proofs, a subtler and more powerfull termination criterion has been implemented. This is an extension of the &amp;quot;size change principle&amp;quot; of Lee, Jones and Ben-Amram [LJ01]. This test successfully checks termination for primitive recursion, lexicographic ordering and permutation of arguments and thus covers most simple practical cases. The implementation is quite similar to the original size-change principle, but the proof of correctness is surprisingly more difficult: see [Hyv10b].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.b - Improvement of the core termination criterion&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
The size-change principle is simple and powerful, but many cases occurring in practice aren&#039;t tagged as terminating. We plan to adapt to PML a termination criterion based on the technique of type-based termination, which allow for recursive calls through size preserving functions such as &amp;lt;tt&amp;gt;List.map&amp;lt;/tt&amp;gt;. There are several possibilities, ranging from simple systems such as the one developed by Abel (RAIRO&#039;04) [Abel04], Barthe et al (MSCS&#039;04) [Bar04] or Blanqui (RTA&#039;04, CSL&#039;05) [Bla04, Bla05c], to the very rich system of Blanqui and Riba (LPAR&#039;06) [BlR06]. In the latter, given for each function some formula in Presburger arithmetic describing how the size of the output is related to the size of the inputs (the correctness of which can be checked automatically), the termination follows from the fact that recursive calls are done on strictly decreasing arguments, using for instance lexicographic or multiset comparisons together with linear combinations of the arguments. Intermediate systems, such as the one of Barthe, Grégoire and Riba (CSL&#039;08) [BGR08] which is powerful but with a lower complexity than Presburger arithmetic, have also to be considered.&lt;br /&gt;
&lt;br /&gt;
This development looks rather orthogonal to the implemented criterion and might require small modification of other parts of PML in order to get the appropriate information. On a different level, slight extensions should be added to the existing criterion to enhance its complexity on some specific examples that are recognized as termination, but not in a reasonable time.&lt;br /&gt;
&lt;br /&gt;
This core termination needs to reach an acceptable compromise between power and simplicity. In particular, the most complex developments may not find their way into the core termination criteria, but rather be used in the next task...&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.c - Use of external provers&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
In order to circumvent the limitations of the core termination criterion, we propose to use external powerful termination provers like [http://aprove.informatik.rwth-aachen.de/ Aprove] or [http://colo6-c703.uibk.ac.at/ttt2/ TTT2] that implement and combine many other termination techniques. To this end, we can define translations from PML programs to one or more of the possible formats currently used in the [http://termination-portal.org/wiki/Termination_Competition annual international competition on termination] and in particular: first-order rewrite systems (TRS), dependency pair problems (DP problem), higher-order rewrite systems (HOTRS) or Haskell programs. In particular, we could reuse some of the techniques used for converting Haskell programs into first-order DP problems in [Gie06].&lt;br /&gt;
&lt;br /&gt;
But to which extent can we trust the results of these provers? Hopefully, now, many termination provers provide certificates in a format called [http://cl-informatik.uibk.ac.at/software/cpf/ CPF] that can be checked by certified, dedicated tools like [http://cl-informatik.uibk.ac.at/software/ceta/ CeTA], [http://color.inria.fr/ Rainbow] or [http://a3pat.ensiie.fr/ CiME3].&lt;br /&gt;
&lt;br /&gt;
The most pragmatic route is simply to trust those tools and concentrate on proving that the translation from (restricted) PML code to the input language is indeed correct. Of course, the ideal solution would be to be able to translate the external certificates into an equivalent PML program whose termination can be infered by the core criterion. The complexity of tools like [http://aprove.informatik.rwth-aachen.de/ Aprove] makes it look very difficult and it is probably hopeless to do that in a general manner.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.d - Modularity and termination&#039;&#039;&#039; (beginning 09/2013, never ending)&lt;br /&gt;
&lt;br /&gt;
The core termination prover does not use the definition of functions to prove their termination, but only information gathered from the typing constraints. When using external prover, for large development, one also would like to avoid sending a large piece of code to the external prover. &lt;br /&gt;
&lt;br /&gt;
Function such as &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; preserves the length of list. But the notion of length does not appear explcitely in the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. This means that the current core termination prover often can not prove termination of a function that use &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. It also means that you need to give the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; to an external tool. &lt;br /&gt;
&lt;br /&gt;
We would like to automatically compute some concise information about the size differences between input and output of program. This means that we would like to infer (when possible) a notion of &#039;&#039;size&#039;&#039; from the definition of a function.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Remark&#039;&#039;&#039;: The halting problem is undecidable, the available external tools for checking termination are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the termination checker.&lt;br /&gt;
&lt;br /&gt;
====Task 3 - compilation ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Wojciech Matyjewicz, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.a - A first compiler using LLVM&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012) LLVM is a compiler infrastructure providing many tools: compilation strategy, virtual instruction set, compiler infrastructure, tools to write high level virtual machines, etc. LLVM is very attractive, because it is rather simple to use (it even has an OCaml interface) and can compile for a bytecode interpreter, can be used as a JIT compiler or a standard compiler. Moreover, it support a lot of platforms. It also provide some optimizations, which is important. We think that writing a compiler, with no optimization, for PML using LLVM should not be too hard (this is important that this task be easy, because this is not really research ...)&lt;br /&gt;
&lt;br /&gt;
A polish phd student Wojciech Matyjewicz has started to work on this in december. He visited the LAMA during one week to start the project. It is important to note that he is a first year phd in Poland and the first year there is equivalent to our Master 2. Which means that Wojciech Matyjewicz is a potential candidate.&lt;br /&gt;
&lt;br /&gt;
Then, we would like to improve our compiler in various direction. We mention here the ones that are innovative in this domain (we should also consider more standard optimization, but we do not mention them specifically). &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.b - Representation of cartesian product and disjoint sum&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012 for product) PML allows only one kind of cartesian product which in general (because of multiple inheritance and implicit subtyping) must be represented as a table (hash-table or maps based on binary search trees). These can impact performance. We plan to generate extra constraints for each occurrence of a constructor of a cartesian product in a program. Then, solving this constraint in a way that maximize speed (or size) should allow for a representation of cartesian product that is more efficient than using, for instance, OCaml. The same kind of optimization (with a different optimization criterion) should be done for sum types and the implementation of pattern matching. This optimisation should be included in the first compiler because the implentation with tables is too costly for a temporary solution.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.c - Unboxing&#039;&#039;&#039; (depends on some parts of 3.b, beginning 1/2012, delivered 1/2013) In general, 32 bits integer and floating point number are boxed (that is represented by a pointer). This allows a more elegant language. This can lead to major impact on performance especially when arrays are involved. We think that constraint-checking is a good framework to propagate type information and allow efficient unboxing. Nevertheless, doing enough unboxing to try to match the performance of low level languages like C is very hard. We hope that we can reuse some of the work of task 3.b, because unboxing can be seen also as the optimization of the representation of a cartesian product with only one field.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.d - compilation of affectation (reference and arrays) and IO&#039;&#039;&#039; (depend upon 1.c, beginning 09/2012, delivered 03/2014) After adapting uniqueness typing to PML (task 1.c), we will be able to compile affectation and IO imperatively as in any imperative programming language.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.e - Garbage collection&#039;&#039;&#039; (beginning 01/2014, delivered 09/2014) For simplicity reasons, the first compiler will simply use Boehm&#039;s garbage collector. This garbage collector is relatively efficient and simple to use. However, Boehm&#039;s GC isn&#039;t optimised for the kind of allocations used in a functional language. Moreover, having a multithreaded GC could prove usefull in moder environment. We thus plan to replace Boehm&#039;s GC by a dedicated GC tuned for our purposes.&lt;br /&gt;
&lt;br /&gt;
Writing a GC that is both efficient and correct is not easy, and this sub-task is rather orthogonal to the PML language, which explains why it only comes later during the project. Nevertheless, we feel it is necessary to go through the trouble if we want to be as efficient (or even better, more efficient) than existing functional languages...&lt;br /&gt;
&lt;br /&gt;
====Task 4 - Automated reasoning====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Frédéric Blanqui&lt;br /&gt;
&lt;br /&gt;
Participants: Frédéric Blanqui, Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
The kernel of the proof engine will be based on completion techniques. Knuth-Bendix completion tries to transform a set of unoriented equations into a set of (inter-reduced and) convergent, that is, terminating and confluent, set of rewrite rules. It can therefore be used for proving that some equality is the equational consequence of some equational theory. Indeed, when an equational theory can be completed into a convergent rewrite system, two terms are equivalent in this equational theory if their normal form in the convergent rewrite systems are equal.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.a - Adaptation of the Knuth-Bendix completion algorithm to PML&#039;&#039;&#039; (already started, delivered 09/2015) As explained just before, Knuth-Bendix completion is based on rewriting. However, in PML, programs are not rewriting systems. We therefore need to adapt Knuth-Bendix completion. We need both generalization, to use the notion of constructor present in ML and take care of the higher-order nature of ML (even if we can not hope much here).&lt;br /&gt;
As said above, something is already implemented, but it is trivial because completely restricted to closed terms. A first version should be able at least to rewrite a closed term modulo some simple equational (and universal) theory. An important point here is to ensure termination&lt;br /&gt;
of this algorithm and even a low complexity. The price to pay, will be incompleteness. A lot of care should also be devoted to the correctness of the implementation, because like for task 3.a, the consistency of PML relies on it.&lt;br /&gt;
&lt;br /&gt;
This task in one of the major task for PML and a first version already exists, but is non terminating in presence of equalities between functions: if we have an equation like &#039;&#039;f = f o f&#039;&#039;, PML may use this equation has a definition of &#039;&#039;f&#039;&#039; and loop. For dealing with these cases, we are considering a fix which involves some notions similar to those of &#039;&#039;geometry of interaction&#039;&#039;. Another particular and very important case of universal equation that we should take into account is associativity and commutativity. It is indeed very important to ease proofs on integers (addition and multiplication are associative and commutative). To this end, we could reuse the [http://cime.lri.fr CiME] library.&lt;br /&gt;
&lt;br /&gt;
Note that this work could benefit to other projects and tools, like [http://moca.inria.fr/ Moca], a generator of construction functions for private data types with algebraic invariants, also based on completion, or Europa, a proof assistant based on the lambda-pi-calculus modulo rewriting developed by Gilles Dowek and [http://www.lix.polytechnique.fr/Labo/Mathieu.Boespflug/ Mathieu Boespflug]. Indeed, currently, Moca generates OCaml code without guarantee on its correctness. Using PML instead, Moca could also generate a proof of the correctness of the generated construction functions.&lt;br /&gt;
Then, later, when trying to prove the correctness of a function defined on this private date type, one can use the invariants satisfied by the values of the private data type as assumptions, since these invariants are satisfied by construction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.b - Use of external provers&#039;&#039;&#039; (beginning 03/2012, delivered 09/2015) Like for termination proofs, in order to increase the proving capacities of PML, we will provide a translation of PML proof goals into the [http://www.cs.miami.edu/~tptp/ TPTP standard format] of the CASC competition in order to be able to use external provers too, and in particular provers based on completion like [http://www.waldmeister.org/ Waldmeister], [http://cime.lri.fr/ CiME] or [http://cl-informatik.uibk.ac.at/mkbtt/ mkbTT] but not only. And possibly some certifying provers like [http://focal.inria.fr/zenon/ Zenon] based on tableaux or [http://alt-ergo.lri.fr/ Alter-Ego] based on SMT (SAT solver modulo theory).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Same remark than for termination&#039;&#039;&#039;: The problem is undecidable, the available external tools for automated reasonning are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the automated reasonning.&lt;br /&gt;
&lt;br /&gt;
====Task 5 - validation (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Christophe Mouilleron, Tom Hirschowitz.&lt;br /&gt;
&lt;br /&gt;
The validation requires to write numerous examples to check that we fulfill our main goal, which is that all programs (with or without proof) are written in the best possible way. This work being research, we think that it is important that any piece of code written in PML that does not look &#039;&#039;right&#039;&#039; is carefully examined to check that this is not due to a defect in language design.&lt;br /&gt;
&lt;br /&gt;
Christophe Mouilleron and Erik Martin-Dorel started to work on the axiomatisation of computer arithmetics within an ongoing PEPS project. This is a good test for PML and moreover a requirement &lt;br /&gt;
because we want PML to be a real programming language and thefore the limited arithmetic of processors (32 and 64 bits integer and floating point number) must be supported by PML. However, proving software using them is not trivial at all and Christophe Mouilleron member of the ARAINER team in ENS Lyon is a specialist in this domain.&lt;br /&gt;
&lt;br /&gt;
Tom Hirshowitz and Christophe Raffalli already started (and almost finished) a proof in PML that &lt;br /&gt;
categories, functors and natural transformations form a 2-category (this development is available in the example directory in the current version of PML). We plan to continue such abstract developments and we think that they could lead to interesting perspectives about the modularity of PML.&lt;br /&gt;
&lt;br /&gt;
More general code, including a standard library and some significant mathematics should be developed (there is already around 10.000 lines of PML code in the current distribution). Moreover, we started to port to PML the course of software foundation written in Coq. The first three files are translated and there remain a dozen of files of around 2500 lines to translate. This is a major work, but would provide a very good test for PML, and a good tutorial.&lt;br /&gt;
&lt;br /&gt;
This task should deliver at least 100.000 lines of PML code to have&lt;br /&gt;
a sufficient corpus to say in which respect we fulfilled our goals.&lt;br /&gt;
&lt;br /&gt;
==== Task 6 - Optimisation of PML (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: C. Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: All (anyone could optimize the part of PML he was involved in).&lt;br /&gt;
&lt;br /&gt;
Some of the choice in the design of PML involve rather complex algorithm. Notably, this is the case of the constraint checking algorithm and completion procedure. The first implementation is not trivial but not optimized either. And very often, we have discoverd and will continue to discover that PML is too slow. This goal of this trasversal task is to ensure that PML is usable. &lt;br /&gt;
&lt;br /&gt;
Currently, some optimisations were already added. For instance, PML uses a sat solver for various &lt;br /&gt;
tasks: completeness and usefulness of cases in pattern matching and dealing with negative &lt;br /&gt;
hypothesis (like &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is not equal to &amp;lt;tt&amp;gt;S[x]&amp;lt;/tt&amp;gt;) in the completion procedure. Improving the sat solver using J.C. Filliâtre work [] and simploifying the formula before giving them to the sat solver were a major improvement.&lt;br /&gt;
&lt;br /&gt;
A lot of other optimisations are planned: &lt;br /&gt;
* The graph used to encode the typing constraints should probably be reduced (that is we should compute its transitive reduction). &lt;br /&gt;
* The completion procedure stores a set of terms of the language and we need a fast way to recover the set of all term using a given sub-term. The current implementation is too naïve. &lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
=== Planning of tasks, deliverables and milestones ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The following diagram represents the summary of the tasks and subtasks, together with the intended planning:&lt;br /&gt;
&lt;br /&gt;
[[Image:pml-gantt.png]]&lt;br /&gt;
&lt;br /&gt;
==Data management, data sharing, intellectual property and results exploitation==&lt;br /&gt;
&lt;br /&gt;
Results in each of the tasks will be published in journals (APAL, TCS, ...) and international conferences as usual (LICS, TLCA, CSL, CIE, ...).&lt;br /&gt;
&lt;br /&gt;
PML language is already distributed as open source software under the Cecill-B license. We think that for such a research platform, this is the only possible way to ensure that people will try it. As soon as a first compiler is available, we plan to produce easy-to-install packages, at least for some well-known Linux distributions (Debian and its derivatives seem a good choice).&lt;br /&gt;
&lt;br /&gt;
==Consortium organization and description==&lt;br /&gt;
&lt;br /&gt;
===Relevance of the partner for the project===&lt;br /&gt;
&lt;br /&gt;
This project involve only one partner, the LAMA (UMR 5127), where the coordinator of the project already developed the proof assistant PhoX. The main characteristic of PhoX is to be rather simple to use due to a set of tactics which is limited (less than 20 for the principal ones), but powerful. Moreover, tactics are extensible by &#039;&#039;incorporating theorems&#039;&#039; inside the tactics.&lt;br /&gt;
&lt;br /&gt;
Clearly, this means that efficiency was the main goal of PhoX. Unfortunately, like all tactical theorem prover, PhoX proofs are not readable. After a few attempts with a Mizar-like mode for PhoX, Christophe Raffalli decided to move to a new theorem prover, starting from scratch.&lt;br /&gt;
&lt;br /&gt;
Pierre Hyvernat is also in Chambery and the second developer of PML (he wrote the current termination checker). Tom Hirshowitz has some prior experience in his phd about the compilation of functional languages. At ENS Lyon, which is very near to Chambéry, Alexandre Miquel is a specialist of consistency proof for logical framework. Therefore, Chambery is the very natural partner for this project.&lt;br /&gt;
&lt;br /&gt;
===Qualification of the project coordinator and members===&lt;br /&gt;
&lt;br /&gt;
The coordinator and various members of the project comes from various horizon (see section 7), but they have a common background around the use and development of programming language and/or formal methods. We think that this variety, the small number of members, should allow for good communication and should be very fruitful. &lt;br /&gt;
&lt;br /&gt;
We think, that compared with the development of PML by Christophe Raffalli alone, such a team should speed up the development of PML approximately by a factor 3, making it possible to deliver a very innovative and useful tool at the end of the project. The lack of support for such a team would certainly limit the tool to an experimental toy with many development only partially (or even not at all) integrated in the project.&lt;br /&gt;
&lt;br /&gt;
Christophe Raffalli will also ask for delegations during the project to be able to spend even more time on it.&lt;br /&gt;
&lt;br /&gt;
==Scientific justification of requested budget==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Meetings (total 9720€ per year)====&lt;br /&gt;
 &lt;br /&gt;
Two meetings and one workshop per year, 3 days each, for 7 people. Each meeting costs&lt;br /&gt;
1 train ticket in France, 3 days and 2 nights:&lt;br /&gt;
3*7*(100 + 3*20 + 2*80) = 6720€. &lt;br /&gt;
&lt;br /&gt;
For the workshop, we have to invite 2 to 3 guests. Some may come from foreign country and we estimate the cost&lt;br /&gt;
to 3000€ per year. Which mean a total of 9720€ per year.&lt;br /&gt;
&lt;br /&gt;
====Visits (total 10000€)====&lt;br /&gt;
&lt;br /&gt;
We think that this is very important for this project to interact with other project.&lt;br /&gt;
For instance, Andreas Abel came to visit Chambéry in 2010 for two weeks financed by our PEPS&lt;br /&gt;
project and during this time induced an important bootstrap to the implementation of the termination checker &lt;br /&gt;
[Hyv10b] and contributed a non trivial example with a proved implentation of left-leaning red-black trees.&lt;br /&gt;
&lt;br /&gt;
We want to continue such interaction. Andreas Abel already agreed as well as Joe Wells for discusion about error reporting and , Assia Mahboubi for complex proofs involving the reflexion principle. Many other discussion would be profitable about PML runtime (with multithreading ?), interaction with external tools (termination checker or automated theorem prover), &lt;br /&gt;
uniqueness typing (meeting with people already using such technics), ...&lt;br /&gt;
&lt;br /&gt;
We plan around 4 short visits of one or two weeks from people outside the project to Chambéry and the same amount for short visit in the other direction. This means around 12 weeks per year with 8 travels for a cost of 500€ per week (x12) plus in average (depending if we use plane or train) the same amount for each travel (x8), with a total of 10000€ per year.&lt;br /&gt;
&lt;br /&gt;
====Conferences (total 9600€ per year)====&lt;br /&gt;
 &lt;br /&gt;
The members of the ANR will submit papers to international conferences and&lt;br /&gt;
journals and attend to specialized workshop. We have 2.5 person/year on the project with means &lt;br /&gt;
around 3 international conferences or workshop per year (estimated cost 2000€) and one national conference or workshop per year (estimated cost 1200€)&lt;br /&gt;
&lt;br /&gt;
====Master internships (total 1500€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We plan to host around four master internships in good conditions (possibly&lt;br /&gt;
followed by PhD studentships not financed by the ANR): one per year with a total cost of&lt;br /&gt;
6000€ (1500€ each: 300€ for travel and 200€ per month for an accommodation at&lt;br /&gt;
the CROUS).&lt;br /&gt;
&lt;br /&gt;
====Computers (total 2000€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We consider that the ANR project has to participate in the renewal of the&lt;br /&gt;
computers of its participants. The lifetime of a computer being 4 years and&lt;br /&gt;
the total number of month for permanent members of the project being 112, we&lt;br /&gt;
think that we should pay for 4 computers with an average value of 2000€ each&lt;br /&gt;
(we need powerful computers and laptops, because automated reasoning requires&lt;br /&gt;
a lot of computations and memory).&lt;br /&gt;
&lt;br /&gt;
====Human resources financed by the ANR (1 PhD student, 2 two years postdocs and 4 month of invited professor)====&lt;br /&gt;
 &lt;br /&gt;
This project involves many tasks and 7 members. However, all members&lt;br /&gt;
apart from the coordinator and Pierre Hyvernat can only devote 2-3 month per year to this project&lt;br /&gt;
(they are involved in other ongoing research). Although this is far from&lt;br /&gt;
negligible, we think that we will need more human power: we estimate that 1&lt;br /&gt;
PhD and 2 postdocs are reasonable. &lt;br /&gt;
&lt;br /&gt;
We also consider that one year post-doc are not sufficient, because the time need to &lt;br /&gt;
understand the existing code base is long and the student has both to write code and &lt;br /&gt;
publish its result. Moreover, the code produced by the student will not be an experimental&lt;br /&gt;
code to support its publication, but code which should remain in the project and be maintened by &lt;br /&gt;
other member of the project. In one year, this seems impossible to achieve.&lt;br /&gt;
&lt;br /&gt;
Moreover, as mentioned in the section about visits, we would like to have 1 month per year of invited professor.&lt;br /&gt;
&lt;br /&gt;
This would give a total 88 months (4 month invited, 36 for the PhD and 48 for the 2 postdocs)&lt;br /&gt;
To be compared with the total of 104/112 month not payed by the ANR. We consider that this is a good balance.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 308589€.&lt;br /&gt;
&lt;br /&gt;
====Human resources not financed by the ANR====&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! month/year&lt;br /&gt;
! percentage&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Raffalli&lt;br /&gt;
| 10&lt;br /&gt;
| 85%&lt;br /&gt;
|-&lt;br /&gt;
| Frédéric Blanqui&lt;br /&gt;
| 4&lt;br /&gt;
| 25%&lt;br /&gt;
|-&lt;br /&gt;
| Emmanuel Chailloux&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Tom Hirshowitz&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Pierre Hyvernat&lt;br /&gt;
| 6&lt;br /&gt;
| 50%&lt;br /&gt;
|-&lt;br /&gt;
| Alexandre Miquel&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Mouilleron&lt;br /&gt;
| 0/2&lt;br /&gt;
| 0/15%&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total per year&#039;&#039;&#039;&lt;br /&gt;
| 26/28&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total for 4 year&#039;&#039;&#039;&lt;br /&gt;
| 104/112&lt;br /&gt;
| &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Remark: the situation of Christophe Mouilleron is unknown next year. If it is possible he will &lt;br /&gt;
continue is work on PML started with the PEPS for around 2 month per year. But if it is not possible, &lt;br /&gt;
or if he is selected for the post-doc position, then we should not count it. We used the worst case&lt;br /&gt;
on the website.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 350333€ snas ternir compte de Christophe Mouilleron.&lt;br /&gt;
&lt;br /&gt;
==Annexes==&lt;br /&gt;
&lt;br /&gt;
===CV, Resume of all project members===&lt;br /&gt;
&lt;br /&gt;
==== Christophe Raffalli (project coordinator) ====&lt;br /&gt;
&lt;br /&gt;
Age 41, MCF at the LAMA (UMR 5127) since September 1997.&lt;br /&gt;
&lt;br /&gt;
After his PhD in Paris VII (defended in February 1994), Christophe Raffalli spent 1 and a half year at the LFCS in Edinburgh, 2 years at Chalmers university in Göteborg (post-doc of the TYPES European project) and 1 year as ATER in Créteil University.&lt;br /&gt;
&lt;br /&gt;
Research administration: For ten years, the LAMA was sub-site of the Paris VII site inside the TYPES project which was renewed several times and Christophe Raffalli was the coordinator for this sub-site. Currently the project is not financed by the E.U. Nevertheless, Christophe Raffalli is in charge of the organization of the next TYPES meeting in Aussois in May 2009.&lt;br /&gt;
&lt;br /&gt;
His research interests include:&lt;br /&gt;
&lt;br /&gt;
* theory and implementation of proof assistants,&lt;br /&gt;
* proof theory,&lt;br /&gt;
* implementation of programming languages (especially type-systems).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Raf10b] &#039;&#039;Realizability for programming languages&#039;&#039; (submitted, available as hal-00474043)&lt;br /&gt;
&lt;br /&gt;
* [Raf08a] &#039;&#039;PML and strong normalisation&#039;&#039; conference at the Types workshop, April 2008, Turino, Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf07b] &#039;&#039;PML: a new proof assistant&#039;&#039; conference at the Types workshop, may 2007, Cividale del Friuli (Udine), Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf06a] &#039;&#039;Realizability of the axiom of choice in HOL (An analysis of Krivines&#039;s work)&#039;&#039; with Frédéric Ruyer in Fundamenta Informaticae (2006)&lt;br /&gt;
&lt;br /&gt;
* [Raf05a] &#039;&#039;PhoX&#039;&#039; with Paul Rozière in The seventeen provers of the World, Freek Wiedijk (editor) LNAI 3600 pages 67-71&lt;br /&gt;
&lt;br /&gt;
* [Raf03b] &#039;&#039;System ST&#039;&#039; Schedae Informatica, proceedings of the Chambery-Krawow-Lyon Workshop, Vol. 12, pages 97-112 (June 2003)&lt;br /&gt;
&lt;br /&gt;
* [Raf02c] &#039;&#039;Getting results from programs extracted from classical proofs&#039;&#039;, TCS 2004, volume 323, pages 49-70&lt;br /&gt;
&lt;br /&gt;
* [Raf02b] &#039;&#039;System ST, beta-reduction and completeness&#039;&#039;, presented at LICS 2003, publication IEEE, pages 21-32&lt;br /&gt;
&lt;br /&gt;
* [Raf02a] &#039;&#039;Computer Assisted Teaching in Mathematics&#039;&#039;, with René David, to appear in the proceedings of the Workshop on 35 years of Automath (April 2002, Edingurgh)&lt;br /&gt;
&lt;br /&gt;
* [Raf01d] &#039;&#039;System ST, towards a Type System for Extraction and Proof of Programs&#039;&#039;, Archive for Pure and Applied Logic, 2003, volume 122, pages 107-130&lt;br /&gt;
&lt;br /&gt;
* [Raf01c] &#039;&#039;Apprentissage du raisonnement assité par ordinateur&#039;&#039;, avec René David, Quadrature numéro 45, printemps 2002, pages 25-36). Version courte parue dans la gazette de la SMF, avril 2002, numéro 92, pages 48-56&lt;br /&gt;
&lt;br /&gt;
==== Frederic Blanqui (INRIA, Rocquencourt) ====&lt;br /&gt;
&lt;br /&gt;
Age 38, permanent full-time researcher at [http://www.inria.fr INRIA].&lt;br /&gt;
&lt;br /&gt;
Frederic Blanqui is expert in the following areas:&lt;br /&gt;
* type theory,&lt;br /&gt;
* rewriting theory,&lt;br /&gt;
* termination,&lt;br /&gt;
* functional programming,&lt;br /&gt;
* proof assistants,&lt;br /&gt;
* and formal certification of program properties.&lt;br /&gt;
&lt;br /&gt;
Since September 2008, he is INRIA researcher at [http://liama.ia.ac.cn LIAMA], the Sino-French Laboratory in Computer Science, Automation and Applied Mathematics.&lt;br /&gt;
&lt;br /&gt;
Between 2003 and 2008, he was INRIA researcher at [http://www.loria.fr LORIA], Nancy, in the Protheo research team led by Pr Claude Kirchner, focusing on the use of rewriting techniques for programming, as well as specifying and proving program properties.&lt;br /&gt;
&lt;br /&gt;
Since 2004, he is leading the [http://color.inria.fr CoLoR] project which aims at providing tools for automatically certifying the termination of programs. Since 2007, CoLoR is the best certification back-end in the international [http://termination-portal.org/wiki/Termination_Competition competition on certified termination provers].&lt;br /&gt;
&lt;br /&gt;
In 2007 and 2008, he led the INRIA [http://quotient.loria.fr/ Quotient] project which aims at extending the [http://caml.inria.fr OCaml] programming language with types whose values automatically satisfy equational invariants using the [http://moca.inria.fr Moca] tool.&lt;br /&gt;
&lt;br /&gt;
He supervised 2 master thesis and 3 PhD students on the extension of type theory with decision procedures, the termination of typed higher-order rule-based programs, and the certification of termination proofs.&lt;br /&gt;
&lt;br /&gt;
He did his PhD with Pr Jean-Pierre Jouannaud at University Paris Sud between October 1998 and September 2001 on the combination of type theory and rewriting theory.&lt;br /&gt;
&lt;br /&gt;
Between October 2001 and August 2002, he worked on the certification of cryptographic protocols with Pr Larry Paulson at Cambridge, UK.&lt;br /&gt;
&lt;br /&gt;
Between September 2002 and September 2003, he worked at Ecole Polytechnique in the [http://coq.inria.fr Coq] development team on the extension of the proof assistant Coq with rewriting.&lt;br /&gt;
&lt;br /&gt;
More details on his activities and publications can be found on his [http://www-rocq.inria.fr/~blanqui/ web page] and in his [http://www-rocq.inria.fr/~blanqui/divers/cv.pdf CV].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
International journals with reading committee: 7&lt;br /&gt;
&lt;br /&gt;
International conferences with reading committee: 15&lt;br /&gt;
&lt;br /&gt;
Other publications (thesis, workshops, invited papers, reports, etc.): 15&lt;br /&gt;
&lt;br /&gt;
Prizes: 2001 [http://www.specif.org/ SPECIF] Award for his PhD thesis by the French national society of teachers and researchers in computer science; and 2001 Kleene Award for the best young researcher paper at the IEEE Symposium on Logic in Computer Science ([http://www2.informatik.hu-berlin.de/lics/ LICS]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Five most significant publications in the last 5 years:&lt;br /&gt;
&lt;br /&gt;
* [Bla11] F. Blanqui and A. Koprowski. &#039;&#039;CoLoR: a Coq library on well-founded rewrite relations and its application to the automated verification of termination certificates&#039;&#039;. To appear in Mathematical Structures in Computer Science.&lt;br /&gt;
&lt;br /&gt;
* [BRK10] F. Blanqui, C. Riba and C. Kirchner. &#039;&#039;On the confluence of lambda-calculus with conditional rewriting&#039;&#039;. Theoretical Computer Science 411(37), p. 3301-3327.&lt;br /&gt;
&lt;br /&gt;
* [BR09] F. Blanqui and C. Roux. &#039;&#039;On the relation between sized-types based termination and semantic labelling&#039;&#039;. CSL&#039;09. LNCS 5771.&lt;br /&gt;
&lt;br /&gt;
* [BJS08] F. Blanqui, J.-P. Jouannaud and P.-Y. Strub. &#039;&#039;From formal proofs to mathematical proofs: a safe, incremental way for building in first-order decision procedures&#039;&#039;. TCS&#039;08. IFIP 273.&lt;br /&gt;
&lt;br /&gt;
* [BHW07] F. Blanqui, Thérèse Hardin and Pierre Weis. &#039;&#039;On the Implementation of Construction Functions for Non-free Concrete Data Types&#039;&#039;. ESOP 2007: 95-109.&lt;br /&gt;
&lt;br /&gt;
==== Emmanuel Chailloux (LIP6, Paris) ====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Age 51,  full professor at the University &lt;br /&gt;
Pierre et Marie Curie ([http://www.upmc.fr UPMC - Paris 6]) in Paris France, &lt;br /&gt;
and since October 2006  researcher at the &lt;br /&gt;
[http://www.lip6.fr LIP6] computer science laboratory (UMR 7606), &lt;br /&gt;
in the &amp;quot;Algorithms, Programs and Resolution&amp;quot; team ([http://www-apr.lip6.fr APR]).&lt;br /&gt;
&lt;br /&gt;
His research work is related to design and implementation of programming languages : &lt;br /&gt;
* semantics, &lt;br /&gt;
* types systems, &lt;br /&gt;
* runtime implementation, &lt;br /&gt;
* multicores. &lt;br /&gt;
Most of the recent publications relate to safety-critical software development.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Recent publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[VWC-2011] Vaugon B., Wang P., Chailloux E. &#039;&#039; Les microcontrôleurs&lt;br /&gt;
PIC programmés en Objective Caml&#039;&#039;. Journées des Langages Applicatifs&lt;br /&gt;
(JFLA&#039;2011), janvier 2011.&lt;br /&gt;
&lt;br /&gt;
[WJC-2010] Wang P., Jonquet A., Chailloux E. &#039;&#039;Non-Intrusive&lt;br /&gt;
Structural Coverage for Objective Caml&#039;&#039;.  5th Workshop on Bytecode&lt;br /&gt;
Semantics, Verification, Analysis and Transformation (Bytecode), 2010.&lt;br /&gt;
&lt;br /&gt;
[PAMCCWMC-2009] Pagano B., Andrieu O., Moniot T., Canou B., Chailloux&lt;br /&gt;
E., Wang P., Manoury P., Colaço J.-L. &#039;&#039;Experience Report: Using&lt;br /&gt;
Objective Caml to develop safety-critical embedded tool in a&lt;br /&gt;
certificaiton framework&#039;&#039;.  International Conference of Functional&lt;br /&gt;
Programming (ICFP&#039;09), 2009.&lt;br /&gt;
&lt;br /&gt;
[CBC-2008] Canou B., Balat V., Chailloux E. &#039;&#039;O&#039;Browser : Objective&lt;br /&gt;
Caml on browsers&#039;&#039;. The 2008 ACM SIGPLAN Workshop on ML, 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;HIRONDML: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 2008, 55--69.&lt;br /&gt;
&lt;br /&gt;
[PACCCMW-2008] Pagano B., Andrieu O., Canou B., Chailloux E., Colaço J.-L., Moniot T., Wang P. &lt;br /&gt;
&#039;&#039;Certified development tools implementation in objective caml.&#039;&#039;  &lt;br /&gt;
International Symposium on Practical Aspects of Declarative Languages (PADL 08), 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;Hirondml: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 (2008) 55-69&lt;br /&gt;
&lt;br /&gt;
[HMC-2007] Henry G., Mauny M., Chailloux E. &#039;&#039;Typer la désérialisation&lt;br /&gt;
sans sérialiser les types&#039;&#039;. Technique et Science Informatiques 26, 9&lt;br /&gt;
(2007) 1067-1090.&lt;br /&gt;
&lt;br /&gt;
[CM-2006] Chailloux E., Mauny M. &#039;&#039;Programmation fonctionnelle&#039;&#039;.&lt;br /&gt;
Encyclopédie de l&#039;informatique et des systèmes d&#039;information (2006)&lt;br /&gt;
1016--1027.&lt;br /&gt;
&lt;br /&gt;
==== Tom Hirshowitz (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
34 ans, CR CNRS (informatique) , LAMA&lt;br /&gt;
&lt;br /&gt;
* 2007         CR CNRS au LAMA (UMR 5127) à Chambéry&lt;br /&gt;
* 2004-2007    CR CNRS au LIP (UMR5668) à Lyon&lt;br /&gt;
* 2003-2004    ATER, équipe Plume, LIP, ENS Lyon&lt;br /&gt;
* 2000-2003    Doctorat (dir.: X. Leroy, INRIA Rocquencourt, projet Cristal)&lt;br /&gt;
* 1999-2000    DEA à Paris 7&lt;br /&gt;
* 1996-2000    Ecole Nationale des Ponts et Chaussées&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;10 publications dans des revues et conférences internationales&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;publications choisies&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
# T. Hirschowitz, X. Leroy, and J. B. Wells. Compilation of extended recursion in call-by-value functional languages, PPDP 2003. Version journal dans Higher-Order and Symbolic Computation 22-1. 2009.&lt;br /&gt;
# R. Garner, T. Hirschowitz, and A. Pardon. Variable Binding, Symmetric Monoidal Closed Theories and Bigraphs. CONCUR&#039;09. 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. Contraction-free Proofs and Finitary Games for Linear Logic. MFPS, 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. A Theory for Game Theories. FSTTCS, 2007.&lt;br /&gt;
# T. Hirschowitz, X. Leroy. Mixin Modules in a Call-by-Value Setting, ESOP, 2002, journal version in ACM Transactions on Programming Languages and Systems, 2005.&lt;br /&gt;
&lt;br /&gt;
==== Pierre Hyvernat (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
Age 30, &amp;quot;maître de conférences&amp;quot; at the Université de Savoie (in Chambéry) since September 2006, member of the [http://www.lama.univ-savoie.fr LAMA].&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2005, under the supervision of Thierry Coquand (Chalmers, Göteborg, Sweden) and Thomas Ehrhard (at the time, IML, Luminy, Marseille, France)&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include&lt;br /&gt;
* denotational semantics,&lt;br /&gt;
* type theory and constructive mathematics.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Hyv10b] &#039;&#039;The Size-Change Termination Principle for Constructor Based Languages&#039;&#039; (hal-00547440, submitted)&lt;br /&gt;
&lt;br /&gt;
* [HHy06] with P. Hancock: &#039;&#039;Programming Interfaces and Basic Topology&#039;&#039;. &amp;quot;Annals of Pure and Applied Logic&amp;quot;, volume 137, January 2006,&lt;br /&gt;
&lt;br /&gt;
* [Hyv05] &#039;&#039;Synchronous Games, Simulations and lambda-calculus&#039;&#039;, proceedings of the &amp;quot;GaLoP&amp;quot; workshop, ETAPS 2005. (journal version submitted to Annals of Pure and Applied Logic),&lt;br /&gt;
&lt;br /&gt;
* [Hyv04] &#039;&#039;Predicate Transformers and Linear Logic: yet another Denotational Model&#039;&#039;, Lecture Notes in Computer Science, vol. 3210, September 2004.&lt;br /&gt;
&lt;br /&gt;
==== Alexandre Miquel (PPS, Paris 7) ====&lt;br /&gt;
&lt;br /&gt;
Age 37, &amp;quot;maître de conférences&amp;quot; at the Université Paris-Diderot (Paris 7) since September 2003, member of [http://www.pps.jussieu.fr/ PPS]. Currently CNRS research associate (&amp;quot;délégation&amp;quot;) in the Plume team at the LIP (ENS Lyon) since September 2008.&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2001, under the supervision of Hugo Herbelin (INRIA/LIX) in the Coq team (now TypiCal).&lt;br /&gt;
&lt;br /&gt;
From October 2001 to August 2002 he was postdoc in the Chalmers Institute of Technology (Göetborg, Sweden) under the supervision of Thierry Coquand, and from September 2002 to August 2003 he was &amp;quot;ATER&amp;quot; at the LRI (Orsay).&lt;br /&gt;
&lt;br /&gt;
He is a specialist of the models of type theory (especially the calculus of constructions) and of the correspondence between set theory and type theory. His research interests also include:&lt;br /&gt;
* logic, proof-theory, rewriting,&lt;br /&gt;
* denotational semantics (set- and domain-theoretic),&lt;br /&gt;
* realizability in classical logic.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
His most significant publications are:&lt;br /&gt;
&lt;br /&gt;
* [Miq07] &#039;&#039;Classical program extraction in the calculus of constructions&#039;&#039; (CSL&#039;07),&lt;br /&gt;
&lt;br /&gt;
* [Miq06] with A. Arbiser and A. Ríos. &#039;&#039;A lambda-calculus with constructors&#039;&#039; (RTA&#039;06),&lt;br /&gt;
&lt;br /&gt;
* [Miq04] &#039;&#039;Lambda-Z: Zermelo&#039;s Set Theory as a PTS with 4 Sorts&#039;&#039; (TYPES&#039;04),&lt;br /&gt;
&lt;br /&gt;
* [Miq03] &#039;&#039;A Strongly Normalising Curry-Howard Correspondence for IZF Set Theory&#039;&#039; (CSL&#039;03),&lt;br /&gt;
&lt;br /&gt;
* [Miq00] &#039;&#039;A Model for Impredicative Type Systems with Universes, Intersection Types and Subtyping&#039;&#039; (LICS&#039;00).&lt;br /&gt;
&lt;br /&gt;
==== Christophe Mouilleron (LIP, ENS de Lyon) ====&lt;br /&gt;
&lt;br /&gt;
Age 26, PhD student in the Arenaire team at the LIP (ENS de Lyon) since September 2008. He works under the supervision of Claude-Pierre Jeannerod (INRIA/LIP) and Gilles Villard (CNRS/LIP).&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include :&lt;br /&gt;
* computer arithmetic,&lt;br /&gt;
* code generation,&lt;br /&gt;
* formal proof of numerical properties in programs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [MouRev10] C. Mouilleron and G. Revy. &#039;&#039;Automatic Generation of Fast and Certified Code for Polynomial Evaluation.&#039;&#039; (submitted, available as ensl-00531721)&lt;br /&gt;
&lt;br /&gt;
* [JeaMou10] C.-P. Jeannerod and C. Mouilleron. &#039;&#039;Computing Specified Generators of Structured Matrix Inverses.&#039;&#039; (ISSAC&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [BJJK+10] C. Bertin, C.-P. Jeannerod, J. Jourdan-Lu, H. Knochel, C. Monat, C. Mouilleron, J.-M. Muller, and G. Revy. &#039;&#039;Techniques and tools for implementing IEEE 754 floating-point arithmetic on VLIW integer processors.&#039;&#039; (PASCO&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [LTdD+10] V. Lefèvre, P. Théveny, F. de Dinechin, C.-P. Jeannerod, C. Mouilleron, D. Pfannholzer, and N. Revol. &#039;&#039;LEMA : Towards a Language for Reliable Arithmetic.&#039;&#039; (PLMMS&#039;10)&lt;br /&gt;
&lt;br /&gt;
===Relevant publications by non participants to the project ===&lt;br /&gt;
&lt;br /&gt;
Here are some publication or resources of interest for the project:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Laguage design and theory:&#039;&#039;&#039;&lt;br /&gt;
* [SOW97] Martin Sulzmann, Martin Odersky, Martin Wehr, &#039;&#039;Type inference with constrained types&#039;&#039;, TAPOS, 1997.&lt;br /&gt;
* [HW04] Christian Haack and J. B. Wells, &#039;&#039;Type error slicing in implicitly typed higher-order languages&#039;&#039;, Sci. Comput. Programming, 50:189-224, 2004.&lt;br /&gt;
* [Ruy06] Frédéric Ruyer, &#039;&#039;Preuves, types et sous-type&#039;&#039;, phd 2006 directed by C. Raffalli.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Termination:&#039;&#039;&#039;&lt;br /&gt;
* [LJ01] Lee, Jones, et al. &#039;&#039;The size-change principle for program termination&#039;&#039; - ACM SIGPLAN Notices - 2001&lt;br /&gt;
* [Abel04] Andreas Abel, &#039;&#039;Termination Checking with Types&#039;&#039; ,Special Issue: Fixed Points in Computer Science (FICS&#039;03 and RAIR&#039;04)&lt;br /&gt;
* [Bar04]   G. Barthe, M. J. Frade  and E. Giménez, L. Pinto and T. Uustalu, &#039;&#039;Type-Based Termination of Recursive Definitions&#039;&#039;, 2004, Mathematical Structures in Computer Science.&lt;br /&gt;
* [Gie06] J. Giesl, S. Swiderski, P. Schneider-Kamp, and R. Thiemann &#039;&#039;Automated Termination Analysis for Haskell: From Term Rewriting to Programming Languages&#039;&#039;, Proceedings of the 17th International Conference on Rewriting Techniques and Applications (RTA-06), Lecture Notes in Computer Science 4098.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;the Clean language:&#039;&#039;&#039;&lt;br /&gt;
* [AGR92] Peter Achten, John van Groningen and Rinus Plasmeijer (1992). &#039;&#039;High-level specification of I/O in functional languages&#039;&#039;, Proc. of the Glasgow workshop on Functional programming, ed. J. Launchbury and P. Sansom, Ayr, Scotland, Springer-Verlag, Workshops in Computing, pp. 1-17.&lt;br /&gt;
* [AcP95] Peter Achten and Rinus Plasmeijer (1995). &#039;&#039;The Ins and Outs of CONCURRENT CLEAN I/O&#039;&#039;, Journal of Functional Programming, 5, 1, pp. 81-110.&lt;br /&gt;
* [AcP97] Peter Achten and Rinus Plasmeijer (1997). &#039;&#039;Interactive Functional Objects in CLEAN&#039;&#039;, Proc. of the 1997 Workshop on the Implementation of Functional Languages (IFL&#039;97), ed. K. Hammond Davie, T., and Clack, C., St.Andrews, Scotland,&lt;br /&gt;
* [VPA07] Edsko de Vries, Rinus Plasmeijer, and David M. Abrahamson, &#039;&#039;Uniqueness Typing Simplified, by Edsko de Vries&#039;&#039;,&lt;br /&gt;
* [http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf the language report] by Rinus Plasmeijer and Marko van Eekelen,&lt;br /&gt;
* [http://clean.cs.ru.nl/ the language homepage].&lt;br /&gt;
&lt;br /&gt;
===Involvement of project participants to other grants, contracts, etc …===&lt;br /&gt;
&lt;br /&gt;
* Frederic Blanqui is involved in the Sino-French ANR SIVES 2009-2011 on SImulation and Verification based platform for developing Embedded Systems.&lt;br /&gt;
* Emmanuel Chailloux is member of the ANR PWD (&amp;quot;Programmation du Web Diffus&amp;quot;), whose leader is Manuel Serrano (Inria), and the FUI [http://opengpu.net/ OpenGPU project].  &lt;br /&gt;
* Tom Hishowitz is involved in the ANR PiCoq the ANR proposals RÉCRÉ and CATHRE.&lt;br /&gt;
* Pierre Hyvernat is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Alexandre Miquel is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Christophe Raffalli is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Remark: the interaction with PML and RÉCRÉ is natural because the proof technics used for ensuring some of the properties of the language PML is réalizability which is one of the théma of the ANR proposal RÉCRÉ.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5075</id>
		<title>ANR PML</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=ANR_PML&amp;diff=5075"/>
		<updated>2011-01-13T11:04:53Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Task 1 - theoretical work, design of the language */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;URL of PML project: &amp;lt;tt&amp;gt;http://lama.univ-savoie.fr/tracpml&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Context and positioning of the proposal==&lt;br /&gt;
&lt;br /&gt;
Ever since FORTRAN appeared fifty years ago, programming languages have been evolving rapidly. These languages now include more and more sophisticated concepts like &amp;quot;objects&amp;quot;, &amp;quot;type inference&amp;quot;, &amp;quot;modules&amp;quot;... However, this richness is also what makes it more and more complex to train programmers and makes it difficult for them to keep up with the innovations and changes in programming languages.&lt;br /&gt;
&lt;br /&gt;
Another orthogonal phenomenon is the emergence of formal methods used in conjunction with various programming languages to test, check or prove software. This introduces another layer to languages in order to write specifications, and sometimes yet another one for proofs. Learning a programming language together with the associated specification/proof languages can take an important effort.&lt;br /&gt;
&lt;br /&gt;
Projects such as [http://www.cs.utexas.edu/users/moore/acl2/ ACL2], the successor of  [http://www.cs.utexas.edu/users/boyer/ftp/nqthm nqthm, the Boyer-Moore theorem prover] uses a rather simple language (namely LISP) both as a programming language and specification language, allowing to keep a unity in the system. Unfortunately, LISP is somewhat limited both as a programming language (no good treatment of sum type, no module system) and a specification language (very limited quantification). Moreover, LISP has no compile-time type-checking, which has proved very useful to detect bugs and automatically assert properties.&lt;br /&gt;
&lt;br /&gt;
The aim of this project is to build a very powerful language (with no loss of expressive power compared to state of the art languages) based on a very small number of simple features. We think this will be possible thanks to recent progress both in the semantics of programming languages and the apparition of new algorithms for type inference based on constraints-solving. In fact, we propose in [RAF10b] an innovative concept derived from the later to enable this: constraints-checking.&lt;br /&gt;
&lt;br /&gt;
Moreover, the language will be used not only as a programming language and a specification language (like in ACL2), but also as the proof language. This is natural for an ML-like language because pattern-matching is a natural and powerful way to make a proof by case analysis. This also means that our tool will follow the &#039;&#039;KISS&#039;&#039; philosophy: relatively few (unified) features, yet powerful.&lt;br /&gt;
&lt;br /&gt;
The idea of a new language arose from the discovery of a new typing algorithm [RAF10b] whose implementation gave birth to a first implementation of PML (Proved ML) by Christophe Raffalli. This implementation is already available from [http://www.lama.univ-savoie.fr/~pml the web page of the language]. However, turning PML into a real tool requires a lot of research and implementation work and this is why we request the help of the ANR. Some of the goals are highlighted in the next sections.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML aproach to proofs of specification is unique&#039;&#039;&#039; PML has no dedicated proof language, but the user can still write proofs! Existing programming languages supporting specifications use two alternatives: automated proofs (ACL2, Why) or proof obligations that the user can prove using specific language (Coq extraction, Focalize, Why). Several systems provide both, the manual proofs being used only when automation fails. PML is very different in spirit: it introduces a new instruction, written with a &amp;quot;scissors symbol&amp;quot; &amp;lt;tt&amp;gt;&#039;&#039;&#039;8&amp;lt;&#039;&#039;&#039;&amp;lt;/tt&amp;gt; to express that the corresponding position in the program is &#039;&#039;dead&#039;&#039;, meaning that it can not be reached during evaluation. This condition is checked by a terminating variant of the Knuth-Bendix completion algorithm. This is rather simple and therefore easier to trust than modern decision procedures. However, it only solves trivial cases: to write complex proofs, the user just uses the same syntax as for programs to do case analysis or induction (&#039;&#039;ie.&#039;&#039; recursive definitions). This means that the user does not need learn a specific proof language and hopefuly implies that PML is easier to learn and probably more adapted to industry that previous solutions.&lt;br /&gt;
&lt;br /&gt;
The logic of PML is just the equational theory of its programming language; and we use variants of Knuth-Bendix completion as a proof-checker. The first experiments with the current implementation are promising. However, Knuth-Bendix procedure in the context of ML is a complex and new research problem. A lot more work is needed, for instance to handle proofs in arithmetic which occur quite often. Here is an example of a proof in arithmetic, checked in the current version of PML. This is not completely satisfactory (hard to write), but shows the use of the language for both proofs and programs and the use of recursive functions for inductive proofs:&lt;br /&gt;
&lt;br /&gt;
  val rec mul_associative x y z |- (x * y) * z == x * (y * z)&lt;br /&gt;
    proof match x with&lt;br /&gt;
      Z[] -&amp;gt; 8&amp;lt; (* trivial case handled automatically by Knuth-Bendix *)&lt;br /&gt;
    | S[x&#039;] -&amp;gt;&lt;br /&gt;
      let _ = mul_associative x&#039; y z in (* There is a syntactic sugar for that... *)&lt;br /&gt;
        (* this adds the fact that (x&#039;*y) * z == x&#039; * (y*z) to the environment *)&lt;br /&gt;
 &lt;br /&gt;
      let _ = mul_right_distributive y (x&#039; * y) z in&lt;br /&gt;
        (* this adds the fact that (y + x&#039;*y) * z == y*z + (x&#039;*y)*z *)&lt;br /&gt;
 &lt;br /&gt;
        (* the environment now contains enough information for Knuth Bendix to handle the rest:&lt;br /&gt;
         *    - x*(y*z)  ==  y*z + x&#039;*(y*z)  : by definition&lt;br /&gt;
         *    - x*y == y + x&#039;*y : by definition&lt;br /&gt;
         *      and so (x*y)*z == (y + x&#039;*z)*z&lt;br /&gt;
         *    - (x&#039;*y) * z == x&#039; * (y*z)  :  by the recursive call to mul_associative&lt;br /&gt;
         *    - (y + x&#039;*y) * z == y*z + (x&#039;*y)*z : by the call to mul_right_distributive  *)&lt;br /&gt;
      8&amp;lt;&lt;br /&gt;
&lt;br /&gt;
Moreover, this style of proof is declarative and relatively readable (like Mizar proofs) while concise at the same time. This is very important when you want to maintain large developments.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;PML is different from the other modern programming languages&#039;&#039;&#039; because its design focuses on a few powerful concepts. One consequence is that it is more difficult for a compiler to produce efficient code. In particular, since PML unifies several notions of products (modules, tuples and records), there is no simple way to choose the internal representation of a product, especially with implicit subtyping. Writing a good compiler for PML will thus require more complex and original optimization schemes (probably driven by typing) than languages like OCaml or Haskell. A Polish student (Wojciech Matyjewicz) is just starting a PhD on this very topic.&lt;br /&gt;
&lt;br /&gt;
Here is a simple example, accepted by the current version of PML, demonstrating product type, sum type and subtyping. We define ternary trees as an extension of binary trees with an implicit subtyping&lt;br /&gt;
relation (all functions accepting binary_trees will accept ternary trees, by ignoring the &amp;lt;tt&amp;gt;middle_son&amp;lt;/tt&amp;gt;):&lt;br /&gt;
&lt;br /&gt;
 type rec binary_tree (A) =&lt;br /&gt;
   [ Nil[] | Node[A with left_son : binary_tree(A); right_son : binary_tree(A)] ; ]&lt;br /&gt;
 type rec ternary_tree(A) =&lt;br /&gt;
   binary_tree({ A with middle_son : ternary_tree(A) ;})&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;PML requires a termination criterion&#039;&#039;&#039; because a proof by induction will just be a normal recursive program. Such a program has to be well-founded in order to correspond to a valid proof. A subset of Haskell can now use the Aprove tool to establish termination for simple programs. However, we want the test to be fully integrated with the language, and be compatible with very modular programs. At the moment, these goals seem difficult to achieve with Aprove or other external termination checkers. A first termination criterion based on Lee, Jones &amp;amp; Ben-Amram&#039;s &amp;quot;size-change termination principle&amp;quot; was implemented by Pierre Hyvernat [Hyv10b]. While this test is quite powerful, it is necessarily incomplete, and quite some work is required to make termination proofs of complex programs tractable.&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical description==&lt;br /&gt;
&lt;br /&gt;
===Background, state of the art===&lt;br /&gt;
&lt;br /&gt;
====Programming language====&lt;br /&gt;
&lt;br /&gt;
The ML programming language, created by Robin Milner &amp;lt;em&amp;gt;et al&amp;lt;/em&amp;gt; in the 80&#039;s has two major distinctive features:&lt;br /&gt;
* Algebraic data-types and pattern matching: data types are basically all constructed using fixpoint, cartesian product (product types) and disjoint union (sum types).&lt;br /&gt;
* Static type inference: the type of every piece of code is automatically inferred using Hindley-Milner algorithm (HM). By by construction, once compiled, an ML program can not crash (no segmentation fault). More precisely, when we do not use unsafe features of the language (like interface with unsafe libraries written in C), if an ML program produces a segmentation fault, then there is a bug in the type-checker or the compiler.&lt;br /&gt;
&lt;br /&gt;
Recent progress in type inference algorithm uses constraint solving. This means that the type system can be described in first-order predicate logic in such a way that a type inference problem is a formula written in a decidable fragment of first-order predicate logic (often the purely existential fragment). Hence, any constraint solver can be turned into a type-checker for ML. These approach is known as HM(X) (see [SOW97]).&lt;br /&gt;
&lt;br /&gt;
There are two problems with this approach:&lt;br /&gt;
* The complexity of constraint solving can be too high for practical use, especially when using a general purpose constraint solver. To our knowledge, there are currently no mainstream implementation of ML based on HM(X).&lt;br /&gt;
* HM(X) does not completely solve the problem of subtyping. The language to express the types constructed by the constraint solver is the same as the language of types used by programmers. With constraints &amp;lt;math&amp;gt;\alpha \subseteq \beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\alpha \subseteq \gamma&amp;lt;/math&amp;gt; for three types &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\beta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\gamma&amp;lt;/math&amp;gt;, the most natural solution is &amp;lt;math&amp;gt;\alpha = \beta \cap \gamma&amp;lt;/math&amp;gt;. This implies that intersection needs to be part of the language for types. This means that constraints such as &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \delta&amp;lt;/math&amp;gt; may also appear and they are problematic to deal with. Similar reasoning shows that constraints of the form &amp;lt;math&amp;gt;\beta \cap \gamma \subseteq \beta&#039; \cup \gamma&#039;&amp;lt;/math&amp;gt; may appear, increasing the complexity of constraint solving by an exponential factor.&lt;br /&gt;
&lt;br /&gt;
PML&#039;s approach is to replace type-inference by &#039;&#039;constraint &amp;lt;u&amp;gt;checking&amp;lt;/u&amp;gt;&#039;&#039; rather than constraint solving: we only check that the constraints are satisfiyable in some model. Type-checking in the current implementation of PML can be seen as a black box ensuring that nothing can go wrong during execution. Moreover, since we do not need to write solutions for the constraints, the language for types can be relatively simple. In fact, the types written by the programmer aren&#039;t even the actual type constraints that are checked: they are syntactic sugar for the projection operator onto the intended type (giving for free nice feature like higher-order parametric types, that is types with parameters which may be themselves types with parameters). In other words, the expression &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; is a synonym for &amp;lt;tt&amp;gt;(id_nat x)&amp;lt;/tt&amp;gt; where&lt;br /&gt;
  val rec id_nat x = match x with&lt;br /&gt;
      Z[] -&amp;gt; Z[]&lt;br /&gt;
    | S[x&#039;] -&amp;gt; S[id_nat x&#039;]&lt;br /&gt;
is defined internally by PML. The constraint generated by &amp;lt;tt&amp;gt;x:nat&amp;lt;/tt&amp;gt; mean exactly that &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is of type &amp;lt;tt&amp;gt;nat&amp;lt;/tt&amp;gt;...&lt;br /&gt;
&lt;br /&gt;
With this approach, we loose type-inference and the ability to display types in error messages. Nevertheless, PML error reporting is quite helpful because, in case of problem, it displays three positions in the code and an error message like this &amp;lt;tt&amp;gt;error at position 1, label &amp;quot;id&amp;quot; projected at position 2 do not appear in the value constructed at position 3&amp;lt;/tt&amp;gt;. This kind of error message is in fact of bounded length and often more useful than OCaml or SML messages. We can understand this as showing three points in the &#039;&#039;slice&#039;&#039; of the error, as introduced by Joe Wells in [HW04].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Proof assistant====&lt;br /&gt;
&lt;br /&gt;
Proof assistants have evolved rapidly since Automath in the 70th. Two main trends coexist: automated proof assistants such as ACL2, PVS and &#039;&#039;safe&#039;&#039; ones such as Coq, Isabelle, PhoX, Lego, HOL, Matita, &amp;lt;em&amp;gt;etc.&amp;lt;/em&amp;gt; The former incorporate very sophisticated automated deduction strategies, with no &#039;&#039;certificate&#039;&#039; for the validity of the proof, while the later require all proofs to be done in a specific framework (like natural deduction or type theory) allowing for a simple check of the proof. The gap between the two approaches tend to be reduced by the emergence of complex tactics (for Coq or Isabelle mainly) which build proofs for the user. For instance Zenon is an advanced automated first-order theorem prover outputing a Coq proof.&lt;br /&gt;
&lt;br /&gt;
The common defect of all these proof assistants is that a proof can not be written nor understood without running the proof assistant. Some proof assistants such as Mizar or Alf do not follow exactly the above scheme: Mizar has a declarative style for proof which is (in theory) readable by a human and checked by a limited checker. (This proof style has been adapted to Coq and Isabelle.) Unfortunately, there is no formal description of the Mizar proof checker. Alf on the other hand is based on proof theory and requires the user to basically write the complete proof tree just leaving out a few details. The logic is very well formalized and simple, but writing proof is tedious and not similar to the usual practice of informal mathematics.&lt;br /&gt;
&lt;br /&gt;
This picture of the world of proof assistants shows that some fundamental work is needed. In the current version of PML, the logic is just an equational theory of the underlying programming language. This is easily described formally. The proof engine is, like in Mizar, a limited automated checker inspired by the Knuth-Bendix completion algorithm (KB). The completion algorithm used in PML had to be adapted to the higher-order constructs of ML-like languages and restricted to ensure termination and an acceptable complexity. The current limitation is probably too strong: it is limited to closed terms and cannot use universal theorems automatically (as in the first example of section 1, where one has to give explicitly the argument to use distributivity).&lt;br /&gt;
&lt;br /&gt;
Nevertheless, preliminary examples in the current version shows that the approach is worth trying: proofs are concise and readable once you know the language. A very encouraging point is that all examples where written without interface. This really means that proofs are readable without the help of a computer.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Rationale highlighting the originality and novelty of the proposal===&lt;br /&gt;
&lt;br /&gt;
The final objective of our project would be a full PML compiler, bootstrapped and completely proved with itself (full bootstrap). This does not exist for any language and is far too ambitious for a four years project.  More realistically, we plan to produce a compiler for PML, written in PML, but not proved in PML yet.&lt;br /&gt;
&lt;br /&gt;
We also want to develop proof-checking in such a way as to allow very elegant proofs, supporting the feasibility of a full bootstrap by various examples, some of them being near to industrial application, some others being algorithms coming from implementation of programming languages.&lt;br /&gt;
&lt;br /&gt;
We have focused the existing development on the quality of the language both for proofs and programs. By quality, we mean easy to understand and write (and therefore, easy to learn). We think that using the programming language as a proof language could make formal methods more attractive to the industry without the defect of systems like PVS and ACL2 where the automated tactics replace the need for a proof language, but are sometimes hard to control and use. For instance, finding the right &#039;&#039;lemmas&#039;&#039; to make a proof possible in ACL2 is quite difficult.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other proof systems devoted to programming.&#039;&#039;&#039; Many other proof systems have been used or specifically developed&lt;br /&gt;
to allow the production of certified code: extraction in Coq, Why with its automated prover Who from the Proval project, Focalize, PVS, ATS, ... None of these system uses the programming language as a proof language. They all have a dedicated language for proofs and even if some of them like Focalize or Coq extraction using a Mizar style mode for proof, have readable proofs, learning the proof language is never trivial. Other systems like PVS, ATS, Why using Who rely on automated deduction. In those cases, the behavior of the automated prover is always hard to predict.&lt;br /&gt;
&lt;br /&gt;
Another selling point is that the logic and programming language are fully integrated. This is not a two level systems like most systems (but not all, ACL2 for instance is fully integrated). In PML, the statements of theorems and their proofs are expressions at the same level than programs. This means that a program can contain specifications that contains program definitions in their statement or proof and so on. This is generally not possible (even in ACL2) and makes it possible to write modules with their specifications.&lt;br /&gt;
&lt;br /&gt;
On of the key idea for this project is that any ML-like programming language has all the features needed for a proof language: case analysis via pattern matching and exception handling, induction, calling previously defined program/theorems. This means that it is natural to explore this direction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Comparison with other programming languages&#039;&#039;&#039;. Another key idea in PML is to develop the language and its proof-checker together. This has a great impact on the design of PML. Let&#039;s illustrate this with a concrete example: exception handling. In ML, there is a&lt;br /&gt;
  try P with e -&amp;gt; R&lt;br /&gt;
but, this is not sufficient to do case analysis on the fact that a program &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises or not an exception. In particular, &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; can be the proof just in case &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; raises an exception. However there is no place holder for the normal case (without exception). This is why we had to introduce a&lt;br /&gt;
  let try x = P in Q with e -&amp;gt; R&lt;br /&gt;
where &amp;lt;tt&amp;gt;R&amp;lt;/tt&amp;gt; is evaluated only when &amp;lt;tt&amp;gt;P&amp;lt;/tt&amp;gt; reduces to a value.&lt;br /&gt;
&lt;br /&gt;
A great number of decisions on the language design comes from the interaction between the development of the programming language and its proof-checker. Another key feature of PML, which makes the project original even as a programming language compared to many other projects of programming language research (GALLIUM, Haskell, Scala, ...) is the use of constraint checking. This choice arises from the fact that we want a language as small as possible, because a proof-checker is complex and therefore, we want to fully unify all sorts of Cartesian product including modules, records, tuples and variant with multiple argument. This is already achieved in the current implementation of PML and to my knowledge, no ML like language have a unique but still powerful notion of Cartesian product.&lt;br /&gt;
&lt;br /&gt;
All the systems previously mentioned allow to prove programs in limited subsets of existing languages like ML or Haskell. The prover has to find ways to deal with those languages&#039; defects rather than improve them...&lt;br /&gt;
&lt;br /&gt;
==Scientific and technical program, project management==&lt;br /&gt;
&lt;br /&gt;
===Specific aims of the proposal===&lt;br /&gt;
&lt;br /&gt;
As said in the previous section, the final objective would be to have a fully bootstrapped PML language: this would mean that PML is entirely written and proved in PML. This would be too ambitious at first, and we chose to focus here on the design of the language plus a proof of concept, that is compilation and proof of various examples, searching to do our best on the following points:&lt;br /&gt;
&lt;br /&gt;
* Natural way of writing programs (Task 1)&lt;br /&gt;
* Efficiency of the code generated by the compiler, despite the heavily use of subtyping (Task 3)&lt;br /&gt;
* Readable and short proofs (Task 1, Task 4)&lt;br /&gt;
* Efficiency of type-checking and compilation (Task 2 and 6)&lt;br /&gt;
* Efficiency of proof-checking (Task 4 and 6)&lt;br /&gt;
* All of the above points need testing, and we created a transverse fifth task for that.&lt;br /&gt;
&lt;br /&gt;
===Project management===&lt;br /&gt;
&lt;br /&gt;
We plan to have one 3 days workshop per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems. We already have the agreement of some people to participate in such meetings: Joe Wells, Assia Mahbouby, Andreas Abel, ...&lt;br /&gt;
We plan to have one 3 days meetings per year with all the members of the project, invited speakers and interested outsiders. We think these meetings are fundamental to keep the project running, inform everybody of the project progress and problems.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We will also organize two project meeting per year, just to keep track of progress, share idea and organize the above workshop and other invitation.&lt;br /&gt;
&lt;br /&gt;
We want also to organize visits of one or two members of the project to visit researcher on similar topic (typically a member of the project could visit one of the invited speaker of our workshop). Members of the project should also travel to conference on the subject like POPL, LICS, CSL, TYPES or the recently created CPP (first conference in 2011).&lt;br /&gt;
&lt;br /&gt;
===Detailed description of the work organized by tasks===&lt;br /&gt;
&lt;br /&gt;
====Task 1 - theoretical work, design of the language ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Alexandre Miquel, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.a - Correctness of the constraint checking algorithm&#039;&#039;&#039; (delivered&lt;br /&gt;
09/2012): [RAF10b] already cover the correctness without polymorphism. A draft version of &lt;br /&gt;
the correctness proof with polymorphism does exist but needs more work. The &lt;br /&gt;
main open problem here is the interaction with the termination-check. The current work &lt;br /&gt;
proves that when constraints are checked, the program can only loop via recursive definitions.&lt;br /&gt;
Then, we would like to prove that the program is terminating if recursive definitions are accepted by the &lt;br /&gt;
termination checker. However, this is non trivial.&lt;br /&gt;
&lt;br /&gt;
This being a central piece of PML, it should be also one&lt;br /&gt;
of the first tests for PML in task 5. We could also prove this part of PML in&lt;br /&gt;
Coq (in fact 2 provers proving themselves and each other correct is a much&lt;br /&gt;
stronger warranty than one prover proving itself).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.b - Consistency of proof-checking&#039;&#039;&#039; (beginning 09/2011, delivered before 09/2013 for the core of the language): This is essential for clearly defining the logic of PML and prove its consistency. This should not be too hard for the core of the language. However, this proof has to be extended to take into account all future extensions of the language and could be seen as a &#039;&#039;permanent task&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.c - Adaptation of uniqueness typing to the context of constraint checking&#039;&#039;&#039; (beginning 09/2012, delivered 01/2014): The current version of PML is a pure functional programming language, with no imperative feature. This is problematic, because input/output is necessary for real programs and affectations are required for efficiency especially when using large arrays. We plan to adapt the approach of the [http://clean.cs.ru.nl/ Clean language] [AGR92], [AcP95], [AcP97], [VPA07]. In Clean, all programs can be analyzed as purely functional programs, but the type system can check that some data are not used any more and reuse the place in memory for other data (allowing affectation). For instance, in such a context writing in a file &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; can be written as &amp;lt;tt&amp;gt;let f&#039; = write f str in ...&amp;lt;/tt&amp;gt;, but the compiler must check that &amp;lt;tt&amp;gt;f&amp;lt;/tt&amp;gt; will not be used anymore implying the equivalence between the standard imperative semantics of writing to file and the purely functional semantics used by proofs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;1.d - Private, abstract and existential types.&#039;&#039;&#039; (beginning 09/2011, delivered&lt;br /&gt;
09/2012 for private type, beginning 09/2012, delivered&lt;br /&gt;
09/2013 for existential types and beginning 09/2013, delivered 09/2015 for abstract&lt;br /&gt;
types)&lt;br /&gt;
 &lt;br /&gt;
Abstract data types hide the definition of a data type and allow the user of&lt;br /&gt;
a library to be sure that his code will continue to work even if the internal&lt;br /&gt;
representation of data are changed. In the context of constraint-checking in&lt;br /&gt;
PML, adding abstract data types seems to be a challenging task. Moreover,&lt;br /&gt;
abstract data-types are a form of existential quantification over types and&lt;br /&gt;
could raise some consistency issues. We hope to find a way to incorporate&lt;br /&gt;
abstract types in PML without loosing coherence.&lt;br /&gt;
 &lt;br /&gt;
A first step would be private data types. They are a very simple yet very powerful mechanism for easily&lt;br /&gt;
ensuring invariants on all values of a data type. This mechanism is as&lt;br /&gt;
follows: the compiler simply checks that the constructors of a data type are&lt;br /&gt;
not used for constructing values. Values are constructed by using construction&lt;br /&gt;
functions, like with abstract data types. However, unlike with abstract data&lt;br /&gt;
types, constructors can still be used as patterns for defining functions by&lt;br /&gt;
pattern-matching. Hence, a library on a private data type is not closed but&lt;br /&gt;
can be extended easily. Private data types are therefore an important and very&lt;br /&gt;
useful feature for defining data structures with complex invariants and&lt;br /&gt;
proving their correctness more easily. They have been implemented in OCaml by&lt;br /&gt;
Pierre Weis and are described in Frédéric Blanqui, Thérèse Hardin and Pierre&lt;br /&gt;
Weis&#039; ESOP&#039;07 paper [BHW07].&lt;br /&gt;
&lt;br /&gt;
A second step would be existential types, which are very similar to abstract types,&lt;br /&gt;
but with no free name for the abstract type. On a logical level, they do imply an existential quantification over types&lt;br /&gt;
which has to be limited to ensure consistency. However existential types do not require the type to have a free name, which corresponds in logic to a definite description operator (similar to Hilbert&#039;s epsilon operator), and this, being connected to the axiom of choice (over types), may be really problematic for consistency. Some work related to this exists in the phd thesis of F. Ruyer, a former student of C. Raffalli [Ruy06].&lt;br /&gt;
&lt;br /&gt;
====Task 2 - termination====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Pierre Hyvernat&lt;br /&gt;
&lt;br /&gt;
Participants: Christophe Raffalli, Andreas Abel, Frederic Blanqui&lt;br /&gt;
&lt;br /&gt;
Remark: this is an essential task, running during the 4 years. There will always be some embarrassing examples that do not work, but could work... both for the core and auxiliary criterion (see below for the distinction) meaning that this research field will remain open forever.&lt;br /&gt;
&lt;br /&gt;
Even if it might be counter-intuitive at first, it is often necessary to write programs whose execution can be infinite. For example, any kind of &amp;quot;server&amp;quot;, or almost any interactive program might have infinite executions. Even in purely mathematical setting, it can be interesting to have intermediary non-terminating functions. Consider a function outputting the stream of prime numbers : even if this function is non-terminating, we might use it in a terminating manner in a proof by requesting the &#039;&#039;n&#039;&#039; first prime numbers.&lt;br /&gt;
&lt;br /&gt;
Since PML uses full recursion (keyword &amp;lt;tt&amp;gt;rec&amp;lt;/tt&amp;gt;), writing such programs is easy. On the other hand, the notion of &amp;quot;terminating&amp;quot;, or &amp;quot;well-founded&amp;quot; recursive function isn&#039;t part of the core of PML: such programs are just special cases of recursive programs. The user will have to specify which functions are in fact terminating and might have to prove it himself when PML cannot infer termination automatically.&lt;br /&gt;
&lt;br /&gt;
Proofs of specifications are just PML programs, and those cannot be allowed to run infinitely. More precisely, even if proof will never be run at all (no computational content), they are required to be well-founded. The consistency of PML relies on this. In order to relieve the user from proving that all proofs are in fact terminating, PML should offer a way to check automatically that (some) functions are terminating. Because the halting problem is undecidable, it is hopeless to do that in all generality, but this is seldom necessary: many proofs terminate for obvious reasons. PML should only work for most of the functions, most of the time (rather than work for all the functions, all the time...)&lt;br /&gt;
&lt;br /&gt;
Technically speaking, PML can infer an error called &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; when it encounters a program which, it thinks, may not terminate. Such an error cannot be captured: this is an error rather than an exception. The property we need to guarantee is that if PML doesn&#039;t infer the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; possible, then the program in question does indeed terminate. If the error &amp;lt;tt&amp;gt;Loop&amp;lt;/tt&amp;gt; is possible for a terminating function, the user can still provide PML with a proof that this error is never raised. PML current syntax for that is &amp;lt;tt&amp;gt;[p proof ... ]&amp;lt;/tt&amp;gt; where &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; is a term and &amp;lt;tt&amp;gt;...&amp;lt;/tt&amp;gt; is a proof that &amp;lt;tt&amp;gt;p&amp;lt;/tt&amp;gt; doesn&#039;t raise any exception nor error (this is the desired property for proofs).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.a - Core termination criterion&#039;&#039;&#039; (delivered 09/2010)&lt;br /&gt;
&lt;br /&gt;
This first test is now part of PML. Since primitive recursive function isn&#039;t enough in practice, even for proofs, a subtler and more powerfull termination criterion has been implemented. This is an extension of the &amp;quot;size change principle&amp;quot; of Lee, Jones and Ben-Amram [LJ01]. This test successfully checks termination for primitive recursion, lexicographic ordering and permutation of arguments and thus covers most simple practical cases. The implementation is quite similar to the original size-change principle, but the proof of correctness is surprisingly more difficult: see [Hyv10b].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.b - Improvement of the core termination criterion&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
The size-change principle is simple and powerful, but many cases occurring in practice aren&#039;t tagged as terminating. We plan to adapt to PML a termination criterion based on the technique of type-based termination, which allow for recursive calls through size preserving functions such as &amp;lt;tt&amp;gt;List.map&amp;lt;/tt&amp;gt;. There are several possibilities, ranging from simple systems such as the one developed by Abel (RAIRO&#039;04) [Abel04], Barthe et al (MSCS&#039;04) [Bar04] or Blanqui (RTA&#039;04, CSL&#039;05) [Bla04, Bla05c], to the very rich system of Blanqui and Riba (LPAR&#039;06) [BlR06]. In the latter, given for each function some formula in Presburger arithmetic describing how the size of the output is related to the size of the inputs (the correctness of which can be checked automatically), the termination follows from the fact that recursive calls are done on strictly decreasing arguments, using for instance lexicographic or multiset comparisons together with linear combinations of the arguments. Intermediate systems, such as the one of Barthe, Grégoire and Riba (CSL&#039;08) [BGR08] which is powerful but with a lower complexity than Presburger arithmetic, have also to be considered.&lt;br /&gt;
&lt;br /&gt;
This development looks rather orthogonal to the implemented criterion and might require small modification of other parts of PML in order to get the appropriate information. On a different level, slight extensions should be added to the existing criterion to enhance its complexity on some specific examples that are recognized as termination, but not in a reasonable time.&lt;br /&gt;
&lt;br /&gt;
This core termination needs to reach an acceptable compromise between power and simplicity. In particular, the most complex developments may not find their way into the core termination criteria, but rather be used in the next task...&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.c - Use of external provers&#039;&#039;&#039; (beginning 09/2011, never ending)&lt;br /&gt;
&lt;br /&gt;
In order to circumvent the limitations of the core termination criterion, we propose to use external powerful termination provers like [http://aprove.informatik.rwth-aachen.de/ Aprove] or [http://colo6-c703.uibk.ac.at/ttt2/ TTT2] that implement and combine many other termination techniques. To this end, we can define translations from PML programs to one or more of the possible formats currently used in the [http://termination-portal.org/wiki/Termination_Competition annual international competition on termination] and in particular: first-order rewrite systems (TRS), dependency pair problems (DP problem), higher-order rewrite systems (HOTRS) or Haskell programs. In particular, we could reuse some of the techniques used for converting Haskell programs into first-order DP problems in [Gie06].&lt;br /&gt;
&lt;br /&gt;
But to which extent can we trust the results of these provers? Hopefully, now, many termination provers provide certificates in a format called [http://cl-informatik.uibk.ac.at/software/cpf/ CPF] that can be checked by certified, dedicated tools like [http://cl-informatik.uibk.ac.at/software/ceta/ CeTA], [http://color.inria.fr/ Rainbow] or [http://a3pat.ensiie.fr/ CiME3].&lt;br /&gt;
&lt;br /&gt;
The most pragmatic route is simply to trust those tools and concentrate on proving that the translation from (restricted) PML code to the input language is indeed correct. Of course, the ideal solution would be to be able to translate the external certificates into an equivalent PML program whose termination can be infered by the core criterion. The complexity of tools like [http://aprove.informatik.rwth-aachen.de/ Aprove] makes it look very difficult and it is probably hopeless to do that in a general manner.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;2.d - Modularity and termination&#039;&#039;&#039; (beginning 09/2013, never ending)&lt;br /&gt;
&lt;br /&gt;
The core termination prover does not use the definition of functions to prove their termination, but only information gathered from the typing constraints. When using external prover, for large development, one also would like to avoid sending a large piece of code to the external prover. &lt;br /&gt;
&lt;br /&gt;
Function such as &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; preserves the length of list. But the notion of length does not appear explcitely in the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. This means that the current core termination prover often can not prove termination of a function that use &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt;. It also means that you need to give the definition of &amp;lt;tt&amp;gt;map&amp;lt;/tt&amp;gt; to an external tool. &lt;br /&gt;
&lt;br /&gt;
We would like to automatically compute some concise information about the size differences between input and output of program. This means that we would like to infer (when possible) a notion of &#039;&#039;size&#039;&#039; from the definition of a function.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Remark&#039;&#039;&#039;: The halting problem is undecidable, the available external tools for checking termination are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the termination checker.&lt;br /&gt;
&lt;br /&gt;
====Task 3 - compilation ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Wojciech Matyjewicz, Tom Hirschowitz&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.a - A first compiler using LLVM&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012) LLVM is a compiler infrastructure providing many tools: compilation strategy, virtual instruction set, compiler infrastructure, tools to write high level virtual machines, etc. LLVM is very attractive, because it is rather simple to use (it even has an OCaml interface) and can compile for a bytecode interpreter, can be used as a JIT compiler or a standard compiler. Moreover, it support a lot of platforms. It also provide some optimizations, which is important. We think that writing a compiler, with no optimization, for PML using LLVM should not be too hard (this is important that this task be easy, because this is not really research ...)&lt;br /&gt;
&lt;br /&gt;
A polish phd student Wojciech Matyjewicz has started to work on this in december. He visited the LAMA during one week to start the project. It is important to note that he is a first year phd in Poland and the first year there is equivalent to our Master 2. Which means that Wojciech Matyjewicz is a potential candidate.&lt;br /&gt;
&lt;br /&gt;
Then, we would like to improve our compiler in various direction. We mention here the ones that are innovative in this domain (we should also consider more standard optimization, but we do not mention them specifically). &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.b - Representation of cartesian product and disjoint sum&#039;&#039;&#039; (beginning 12/2010, delivered 1/2012 for product) PML allows only one kind of cartesian product which in general (because of multiple inheritance and implicit subtyping) must be represented as a table (hash-table or maps based on binary search trees). These can impact performance. We plan to generate extra constraints for each occurrence of a constructor of a cartesian product in a program. Then, solving this constraint in a way that maximize speed (or size) should allow for a representation of cartesian product that is more efficient than using, for instance, OCaml. The same kind of optimization (with a different optimization criterion) should be done for sum types and the implementation of pattern matching. This optimisation should be included in the first compiler because the implentation with tables is too costly for a temporary solution.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.c - Unboxing&#039;&#039;&#039; (depends on some parts of 3.b, beginning 1/2012, delivered 1/2013) In general, 32 bits integer and floating point number are boxed (that is represented by a pointer). This allows a more elegant language. This can lead to major impact on performance especially when arrays are involved. We think that constraint-checking is a good framework to propagate type information and allow efficient unboxing. Nevertheless, doing enough unboxing to try to match the performance of low level languages like C is very hard. We hope that we can reuse some of the work of task 3.b, because unboxing can be seen also as the optimization of the representation of a cartesian product with only one field.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.d - compilation of affectation (reference and arrays) and IO&#039;&#039;&#039; (depend upon 1.c, beginning 09/2012, delivered 03/2014) After adapting uniqueness typing to PML (task 1.c), we will be able to compile affectation and IO imperatively as in any imperative programming language.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;3.e - Garbage collection&#039;&#039;&#039; (beginning 01/2014, delivered 09/2014) For simplicity reasons, the first compiler will simply use Boehm&#039;s garbage collector. This garbage collector is relatively efficient and simple to use. However, Boehm&#039;s GC isn&#039;t optimised for the kind of allocations used in a functional language. Moreover, having a multithreaded GC could prove usefull in moder environment. We thus plan to replace Boehm&#039;s GC by a dedicated GC tuned for our purposes.&lt;br /&gt;
&lt;br /&gt;
Writing a GC that is both efficient and correct is not easy, and this sub-task is rather orthogonal to the PML language, which explains why it only comes later during the project. Nevertheless, we feel it is necessary to go through the trouble if we want to be as efficient (or even better, more efficient) than existing functional languages...&lt;br /&gt;
&lt;br /&gt;
====Task 4 - Automated reasoning====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Frédéric Blanqui&lt;br /&gt;
&lt;br /&gt;
Participants: Frédéric Blanqui, Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
The kernel of the proof engine will be based on completion techniques. Knuth-Bendix completion tries to transform a set of unoriented equations into a set of (inter-reduced and) convergent, that is, terminating and confluent, set of rewrite rules. It can therefore be used for proving that some equality is the equational consequence of some equational theory. Indeed, when an equational theory can be completed into a convergent rewrite system, two terms are equivalent in this equational theory if their normal form in the convergent rewrite systems are equal.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.a - Adaptation of the Knuth-Bendix completion algorithm to PML&#039;&#039;&#039; (already started, delivered 09/2015) As explained just before, Knuth-Bendix completion is based on rewriting. However, in PML, programs are not rewriting systems. We therefore need to adapt Knuth-Bendix completion. We need both generalization, to use the notion of constructor present in ML and take care of the higher-order nature of ML (even if we can not hope much here).&lt;br /&gt;
As said above, something is already implemented, but it is trivial because completely restricted to closed terms. A first version should be able at least to rewrite a closed term modulo some simple equational (and universal) theory. An important point here is to ensure termination&lt;br /&gt;
of this algorithm and even a low complexity. The price to pay, will be incompleteness. A lot of care should also be devoted to the correctness of the implementation, because like for task 3.a, the consistency of PML relies on it.&lt;br /&gt;
&lt;br /&gt;
This task in one of the major task for PML and a first version already exists, but is non terminating in presence of equalities between functions: if we have an equation like &#039;&#039;f = f o f&#039;&#039;, PML may use this equation has a definition of &#039;&#039;f&#039;&#039; and loop. For dealing with these cases, we are considering a fix which involves some notions similar to those of &#039;&#039;geometry of interaction&#039;&#039;. Another particular and very important case of universal equation that we should take into account is associativity and commutativity. It is indeed very important to ease proofs on integers (addition and multiplication are associative and commutative). To this end, we could reuse the [http://cime.lri.fr CiME] library.&lt;br /&gt;
&lt;br /&gt;
Note that this work could benefit to other projects and tools, like [http://moca.inria.fr/ Moca], a generator of construction functions for private data types with algebraic invariants, also based on completion, or Europa, a proof assistant based on the lambda-pi-calculus modulo rewriting developed by Gilles Dowek and [http://www.lix.polytechnique.fr/Labo/Mathieu.Boespflug/ Mathieu Boespflug]. Indeed, currently, Moca generates OCaml code without guarantee on its correctness. Using PML instead, Moca could also generate a proof of the correctness of the generated construction functions.&lt;br /&gt;
Then, later, when trying to prove the correctness of a function defined on this private date type, one can use the invariants satisfied by the values of the private data type as assumptions, since these invariants are satisfied by construction.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;4.b - Use of external provers&#039;&#039;&#039; (beginning 03/2012, delivered 09/2015) Like for termination proofs, in order to increase the proving capacities of PML, we will provide a translation of PML proof goals into the [http://www.cs.miami.edu/~tptp/ TPTP standard format] of the CASC competition in order to be able to use external provers too, and in particular provers based on completion like [http://www.waldmeister.org/ Waldmeister], [http://cime.lri.fr/ CiME] or [http://cl-informatik.uibk.ac.at/mkbtt/ mkbTT] but not only. And possibly some certifying provers like [http://focal.inria.fr/zenon/ Zenon] based on tableaux or [http://alt-ergo.lri.fr/ Alter-Ego] based on SMT (SAT solver modulo theory).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Same remark than for termination&#039;&#039;&#039;: The problem is undecidable, the available external tools for automated reasonning are always evolving (new systems are developped, old systems are changed or abandonned). This implies that this task will in fact never end and we will always try to improve the automated reasonning.&lt;br /&gt;
&lt;br /&gt;
====Task 5 - validation (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: Christophe Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: Pierre Hyvernat, Christophe Mouilleron, Tom Hisrshowitz.&lt;br /&gt;
&lt;br /&gt;
The validation requires to write numerous examples to check that we fulfill our main goal, which is that all programs (with or without proof) are written in the best possible way. This work being research, we think that it is important that any piece of code written in PML that does not look &#039;&#039;right&#039;&#039; is carefully examined to check that this is not due to a defect in language design.&lt;br /&gt;
&lt;br /&gt;
Christophe Mouilleron and Erik Martin-Dorel started to work on the axiomatisation of computer arithmetics within an ongoing PEPS project. This is a good test for PML and moreover a requirement &lt;br /&gt;
because we want PML to be a real programming language and thefore the limited arithmetic of processors (32 and 64 bits integer and floating point number) must be supported by PML. However, proving software using them is not trivial at all and Christophe Mouilleron member of the ARAINER team in ENS Lyon is a specialist in this domain.&lt;br /&gt;
&lt;br /&gt;
Tom Hirshowitz and Christophe Raffalli already started (and almost finished) a proof in PML that &lt;br /&gt;
category form a 2-category (this delopment is available in the example directory in the current version of PML). We plan to continue with Tom such abstract development and we think that they could lead to interesting perspective about the modularity of PML.&lt;br /&gt;
&lt;br /&gt;
More general code, including a standard library and some significant mathematical should be developped (there is already around 10.000 lines of PML code in the current distribution). Moreover, we started to port to PML the course of software foundation written in Coq. The three first files are translated and there remain a dozen of files of around 2500 lines to translate. This is a major work, but would provide a very good test for PML and a good tutorial.&lt;br /&gt;
&lt;br /&gt;
This task should deliver at least 100.000 lines of PML code to have&lt;br /&gt;
a sufficient corpus to say in which respect we fulfilled our goals.&lt;br /&gt;
&lt;br /&gt;
==== Task 6 - Optimisation of PML (transverse task) ====&lt;br /&gt;
&lt;br /&gt;
Coordinator: C. Raffalli&lt;br /&gt;
&lt;br /&gt;
Participants: All (anyone could optimize the part of PML he was involved in).&lt;br /&gt;
&lt;br /&gt;
Some of the choice in the design of PML involve rather complex algorithm. Notably, this is the case of the constraint checking algorithm and completion procedure. The first implementation is not trivial but not optimized either. And very often, we have discoverd and will continue to discover that PML is too slow. This goal of this trasversal task is to ensure that PML is usable. &lt;br /&gt;
&lt;br /&gt;
Currently, some optimisations were already added. For instance, PML uses a sat solver for various &lt;br /&gt;
tasks: completeness and usefulness of cases in pattern matching and dealing with negative &lt;br /&gt;
hypothesis (like &amp;lt;tt&amp;gt;x&amp;lt;/tt&amp;gt; is not equal to &amp;lt;tt&amp;gt;S[x]&amp;lt;/tt&amp;gt;) in the completion procedure. Improving the sat solver using J.C. Filliâtre work [] and simploifying the formula before giving them to the sat solver were a major improvement.&lt;br /&gt;
&lt;br /&gt;
A lot of other optimisations are planned: &lt;br /&gt;
* The graph used to encode the typing constraints should probably be reduced (that is we should compute its transitive reduction). &lt;br /&gt;
* The completion procedure stores a set of terms of the language and we need a fast way to recover the set of all term using a given sub-term. The current implementation is too naïve. &lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
=== Planning of tasks, deliverables and milestones ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The following diagram represents the summary of the tasks and subtasks, together with the intended planning:&lt;br /&gt;
&lt;br /&gt;
[[Image:pml-gantt.png]]&lt;br /&gt;
&lt;br /&gt;
==Data management, data sharing, intellectual property and results exploitation==&lt;br /&gt;
&lt;br /&gt;
Results in each of the tasks will be published in journals (APAL, TCS, ...) and international conferences as usual (LICS, TLCA, CSL, CIE, ...).&lt;br /&gt;
&lt;br /&gt;
PML language is already distributed as open source software under the Cecill-B license. We think that for such a research platform, this is the only possible way to ensure that people will try it. As soon as a first compiler is available, we plan to produce easy-to-install packages, at least for some well-known Linux distributions (Debian and its derivatives seem a good choice).&lt;br /&gt;
&lt;br /&gt;
==Consortium organization and description==&lt;br /&gt;
&lt;br /&gt;
===Relevance of the partner for the project===&lt;br /&gt;
&lt;br /&gt;
This project involve only one partner, the LAMA (UMR 5127), where the coordinator of the project already developed the proof assistant PhoX. The main characteristic of PhoX is to be rather simple to use due to a set of tactics which is limited (less than 20 for the principal ones), but powerful. Moreover, tactics are extensible by &#039;&#039;incorporating theorems&#039;&#039; inside the tactics.&lt;br /&gt;
&lt;br /&gt;
Clearly, this means that efficiency was the main goal of PhoX. Unfortunately, like all tactical theorem prover, PhoX proofs are not readable. After a few attempts with a Mizar-like mode for PhoX, Christophe Raffalli decided to move to a new theorem prover, starting from scratch.&lt;br /&gt;
&lt;br /&gt;
Pierre Hyvernat is also in Chambery and the second developer of PML (he wrote the current termination checker). Tom Hirshowitz has some prior experience in his phd about the compilation of functional languages. At ENS Lyon, which is very near to Chambéry, Alexandre Miquel is a specialist of consistency proof for logical framework. Therefore, Chambery is the very natural partner for this project.&lt;br /&gt;
&lt;br /&gt;
===Qualification of the project coordinator and members===&lt;br /&gt;
&lt;br /&gt;
The coordinator and various members of the project comes from various horizon (see section 7), but they have a common background around the use and development of programming language and/or formal methods. We think that this variety, the small number of members, should allow for good communication and should be very fruitful. &lt;br /&gt;
&lt;br /&gt;
We think, that compared with the development of PML by Christophe Raffalli alone, such a team should speed up the development of PML approximately by a factor 3, making it possible to deliver a very innovative and useful tool at the end of the project. The lack of support for such a team would certainly limit the tool to an experimental toy with many development only partially (or even not at all) integrated in the project.&lt;br /&gt;
&lt;br /&gt;
Christophe Raffalli will also ask for delegations during the project to be able to spend even more time on it.&lt;br /&gt;
&lt;br /&gt;
==Scientific justification of requested budget==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
====Meetings (total 9720€ per year)====&lt;br /&gt;
 &lt;br /&gt;
Two meetings and one workshop per year, 3 days each, for 7 people. Each meeting costs&lt;br /&gt;
1 train ticket in France, 3 days and 2 nights:&lt;br /&gt;
3*7*(100 + 3*20 + 2*80) = 6720€. &lt;br /&gt;
&lt;br /&gt;
For the workshop, we have to invite 2 to 3 guests. Some may come from foreign country and we estimate the cost&lt;br /&gt;
to 3000€ per year. Which mean a total of 9720€ per year.&lt;br /&gt;
&lt;br /&gt;
====Visits (total 10000€)====&lt;br /&gt;
&lt;br /&gt;
We think that this is very important for this project to interact with other project.&lt;br /&gt;
For instance, Andreas Abel came to visit Chambéry in 2010 for two weeks financed by our PEPS&lt;br /&gt;
project and during this time induced an important bootstrap to the implementation of the termination checker &lt;br /&gt;
[Hyv10b] and contributed a non trivial example with a proved implentation of left-leaning red-black trees.&lt;br /&gt;
&lt;br /&gt;
We want to continue such interaction. Andreas Abel already agreed as well as Joe Wells for discusion about error reporting and , Assia Mahboubi for complex proofs involving the reflexion principle. Many other discussion would be profitable about PML runtime (with multithreading ?), interaction with external tools (termination checker or automated theorem prover), &lt;br /&gt;
uniqueness typing (meeting with people already using such technics), ...&lt;br /&gt;
&lt;br /&gt;
We plan around 4 short visits of one or two weeks from people outside the project to Chambéry and the same amount for short visit in the other direction. This means around 12 weeks per year with 8 travels for a cost of 500€ per week (x12) plus in average (depending if we use plane or train) the same amount for each travel (x8), with a total of 10000€ per year.&lt;br /&gt;
&lt;br /&gt;
====Conferences (total 9600€ per year)====&lt;br /&gt;
 &lt;br /&gt;
The members of the ANR will submit papers to international conferences and&lt;br /&gt;
journals and attend to specialized workshop. We have 2.5 person/year on the project with means &lt;br /&gt;
around 3 international conferences or workshop per year (estimated cost 2000€) and one national conference or workshop per year (estimated cost 1200€)&lt;br /&gt;
&lt;br /&gt;
====Master internships (total 1500€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We plan to host around four master internships in good conditions (possibly&lt;br /&gt;
followed by PhD studentships not financed by the ANR): one per year with a total cost of&lt;br /&gt;
6000€ (1500€ each: 300€ for travel and 200€ per month for an accommodation at&lt;br /&gt;
the CROUS).&lt;br /&gt;
&lt;br /&gt;
====Computers (total 2000€ per year)====&lt;br /&gt;
 &lt;br /&gt;
We consider that the ANR project has to participate in the renewal of the&lt;br /&gt;
computers of its participants. The lifetime of a computer being 4 years and&lt;br /&gt;
the total number of month for permanent members of the project being 112, we&lt;br /&gt;
think that we should pay for 4 computers with an average value of 2000€ each&lt;br /&gt;
(we need powerful computers and laptops, because automated reasoning requires&lt;br /&gt;
a lot of computations and memory).&lt;br /&gt;
&lt;br /&gt;
====Human resources financed by the ANR (1 PhD student, 2 two years postdocs and 4 month of invited professor)====&lt;br /&gt;
 &lt;br /&gt;
This project involves many tasks and 7 members. However, all members&lt;br /&gt;
apart from the coordinator and Pierre Hyvernat can only devote 2-3 month per year to this project&lt;br /&gt;
(they are involved in other ongoing research). Although this is far from&lt;br /&gt;
negligible, we think that we will need more human power: we estimate that 1&lt;br /&gt;
PhD and 2 postdocs are reasonable. &lt;br /&gt;
&lt;br /&gt;
We also consider that one year post-doc are not sufficient, because the time need to &lt;br /&gt;
understand the existing code base is long and the student has both to write code and &lt;br /&gt;
publish its result. Moreover, the code produced by the student will not be an experimental&lt;br /&gt;
code to support its publication, but code which should remain in the project and be maintened by &lt;br /&gt;
other member of the project. In one year, this seems impossible to achieve.&lt;br /&gt;
&lt;br /&gt;
Moreover, as mentioned in the section about visits, we would like to have 1 month per year of invited professor.&lt;br /&gt;
&lt;br /&gt;
This would give a total 88 months (4 month invited, 36 for the PhD and 48 for the 2 postdocs)&lt;br /&gt;
To be compared with the total of 104/112 month not payed by the ANR. We consider that this is a good balance.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 308589€.&lt;br /&gt;
&lt;br /&gt;
====Human resources not financed by the ANR====&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
! Name&lt;br /&gt;
! month/year&lt;br /&gt;
! percentage&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Raffalli&lt;br /&gt;
| 10&lt;br /&gt;
| 85%&lt;br /&gt;
|-&lt;br /&gt;
| Frédéric Blanqui&lt;br /&gt;
| 4&lt;br /&gt;
| 25%&lt;br /&gt;
|-&lt;br /&gt;
| Emmanuel Chailloux&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Tom Hirshowitz&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Pierre Hyvernat&lt;br /&gt;
| 6&lt;br /&gt;
| 50%&lt;br /&gt;
|-&lt;br /&gt;
| Alexandre Miquel&lt;br /&gt;
| 2&lt;br /&gt;
| 15%&lt;br /&gt;
|-&lt;br /&gt;
| Christophe Mouilleron&lt;br /&gt;
| 0/2&lt;br /&gt;
| 0/15%&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total per year&#039;&#039;&#039;&lt;br /&gt;
| 26/28&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;Total for 4 year&#039;&#039;&#039;&lt;br /&gt;
| 104/112&lt;br /&gt;
| &lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Remark: the situation of Christophe Mouilleron is unknown next year. If it is possible he will &lt;br /&gt;
continue is work on PML started with the PEPS for around 2 month per year. But if it is not possible, &lt;br /&gt;
or if he is selected for the post-doc position, then we should not count it. We used the worst case&lt;br /&gt;
on the website.&lt;br /&gt;
&lt;br /&gt;
Le coût total est de 350333€ snas ternir compte de Christophe Mouilleron.&lt;br /&gt;
&lt;br /&gt;
==Annexes==&lt;br /&gt;
&lt;br /&gt;
===CV, Resume of all project members===&lt;br /&gt;
&lt;br /&gt;
==== Christophe Raffalli (project coordinator) ====&lt;br /&gt;
&lt;br /&gt;
Age 41, MCF at the LAMA (UMR 5127) since September 1997.&lt;br /&gt;
&lt;br /&gt;
After his PhD in Paris VII (defended in February 1994), Christophe Raffalli spent 1 and a half year at the LFCS in Edinburgh, 2 years at Chalmers university in Göteborg (post-doc of the TYPES European project) and 1 year as ATER in Créteil University.&lt;br /&gt;
&lt;br /&gt;
Research administration: For ten years, the LAMA was sub-site of the Paris VII site inside the TYPES project which was renewed several times and Christophe Raffalli was the coordinator for this sub-site. Currently the project is not financed by the E.U. Nevertheless, Christophe Raffalli is in charge of the organization of the next TYPES meeting in Aussois in May 2009.&lt;br /&gt;
&lt;br /&gt;
His research interests include:&lt;br /&gt;
&lt;br /&gt;
* theory and implementation of proof assistants,&lt;br /&gt;
* proof theory,&lt;br /&gt;
* implementation of programming languages (especially type-systems).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Raf10b] &#039;&#039;Realizability for programming languages&#039;&#039; (submitted, available as hal-00474043)&lt;br /&gt;
&lt;br /&gt;
* [Raf08a] &#039;&#039;PML and strong normalisation&#039;&#039; conference at the Types workshop, April 2008, Turino, Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf07b] &#039;&#039;PML: a new proof assistant&#039;&#039; conference at the Types workshop, may 2007, Cividale del Friuli (Udine), Italy&lt;br /&gt;
&lt;br /&gt;
* [Raf06a] &#039;&#039;Realizability of the axiom of choice in HOL (An analysis of Krivines&#039;s work)&#039;&#039; with Frédéric Ruyer in Fundamenta Informaticae (2006)&lt;br /&gt;
&lt;br /&gt;
* [Raf05a] &#039;&#039;PhoX&#039;&#039; with Paul Rozière in The seventeen provers of the World, Freek Wiedijk (editor) LNAI 3600 pages 67-71&lt;br /&gt;
&lt;br /&gt;
* [Raf03b] &#039;&#039;System ST&#039;&#039; Schedae Informatica, proceedings of the Chambery-Krawow-Lyon Workshop, Vol. 12, pages 97-112 (June 2003)&lt;br /&gt;
&lt;br /&gt;
* [Raf02c] &#039;&#039;Getting results from programs extracted from classical proofs&#039;&#039;, TCS 2004, volume 323, pages 49-70&lt;br /&gt;
&lt;br /&gt;
* [Raf02b] &#039;&#039;System ST, beta-reduction and completeness&#039;&#039;, presented at LICS 2003, publication IEEE, pages 21-32&lt;br /&gt;
&lt;br /&gt;
* [Raf02a] &#039;&#039;Computer Assisted Teaching in Mathematics&#039;&#039;, with René David, to appear in the proceedings of the Workshop on 35 years of Automath (April 2002, Edingurgh)&lt;br /&gt;
&lt;br /&gt;
* [Raf01d] &#039;&#039;System ST, towards a Type System for Extraction and Proof of Programs&#039;&#039;, Archive for Pure and Applied Logic, 2003, volume 122, pages 107-130&lt;br /&gt;
&lt;br /&gt;
* [Raf01c] &#039;&#039;Apprentissage du raisonnement assité par ordinateur&#039;&#039;, avec René David, Quadrature numéro 45, printemps 2002, pages 25-36). Version courte parue dans la gazette de la SMF, avril 2002, numéro 92, pages 48-56&lt;br /&gt;
&lt;br /&gt;
==== Frederic Blanqui (INRIA, Rocquencourt) ====&lt;br /&gt;
&lt;br /&gt;
Age 38, permanent full-time researcher at [http://www.inria.fr INRIA].&lt;br /&gt;
&lt;br /&gt;
Frederic Blanqui is expert in the following areas:&lt;br /&gt;
* type theory,&lt;br /&gt;
* rewriting theory,&lt;br /&gt;
* termination,&lt;br /&gt;
* functional programming,&lt;br /&gt;
* proof assistants,&lt;br /&gt;
* and formal certification of program properties.&lt;br /&gt;
&lt;br /&gt;
Since September 2008, he is INRIA researcher at [http://liama.ia.ac.cn LIAMA], the Sino-French Laboratory in Computer Science, Automation and Applied Mathematics.&lt;br /&gt;
&lt;br /&gt;
Between 2003 and 2008, he was INRIA researcher at [http://www.loria.fr LORIA], Nancy, in the Protheo research team led by Pr Claude Kirchner, focusing on the use of rewriting techniques for programming, as well as specifying and proving program properties.&lt;br /&gt;
&lt;br /&gt;
Since 2004, he is leading the [http://color.inria.fr CoLoR] project which aims at providing tools for automatically certifying the termination of programs. Since 2007, CoLoR is the best certification back-end in the international [http://termination-portal.org/wiki/Termination_Competition competition on certified termination provers].&lt;br /&gt;
&lt;br /&gt;
In 2007 and 2008, he led the INRIA [http://quotient.loria.fr/ Quotient] project which aims at extending the [http://caml.inria.fr OCaml] programming language with types whose values automatically satisfy equational invariants using the [http://moca.inria.fr Moca] tool.&lt;br /&gt;
&lt;br /&gt;
He supervised 2 master thesis and 3 PhD students on the extension of type theory with decision procedures, the termination of typed higher-order rule-based programs, and the certification of termination proofs.&lt;br /&gt;
&lt;br /&gt;
He did his PhD with Pr Jean-Pierre Jouannaud at University Paris Sud between October 1998 and September 2001 on the combination of type theory and rewriting theory.&lt;br /&gt;
&lt;br /&gt;
Between October 2001 and August 2002, he worked on the certification of cryptographic protocols with Pr Larry Paulson at Cambridge, UK.&lt;br /&gt;
&lt;br /&gt;
Between September 2002 and September 2003, he worked at Ecole Polytechnique in the [http://coq.inria.fr Coq] development team on the extension of the proof assistant Coq with rewriting.&lt;br /&gt;
&lt;br /&gt;
More details on his activities and publications can be found on his [http://www-rocq.inria.fr/~blanqui/ web page] and in his [http://www-rocq.inria.fr/~blanqui/divers/cv.pdf CV].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
International journals with reading committee: 7&lt;br /&gt;
&lt;br /&gt;
International conferences with reading committee: 15&lt;br /&gt;
&lt;br /&gt;
Other publications (thesis, workshops, invited papers, reports, etc.): 15&lt;br /&gt;
&lt;br /&gt;
Prizes: 2001 [http://www.specif.org/ SPECIF] Award for his PhD thesis by the French national society of teachers and researchers in computer science; and 2001 Kleene Award for the best young researcher paper at the IEEE Symposium on Logic in Computer Science ([http://www2.informatik.hu-berlin.de/lics/ LICS]).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Five most significant publications in the last 5 years:&lt;br /&gt;
&lt;br /&gt;
* [Bla11] F. Blanqui and A. Koprowski. &#039;&#039;CoLoR: a Coq library on well-founded rewrite relations and its application to the automated verification of termination certificates&#039;&#039;. To appear in Mathematical Structures in Computer Science.&lt;br /&gt;
&lt;br /&gt;
* [BRK10] F. Blanqui, C. Riba and C. Kirchner. &#039;&#039;On the confluence of lambda-calculus with conditional rewriting&#039;&#039;. Theoretical Computer Science 411(37), p. 3301-3327.&lt;br /&gt;
&lt;br /&gt;
* [BR09] F. Blanqui and C. Roux. &#039;&#039;On the relation between sized-types based termination and semantic labelling&#039;&#039;. CSL&#039;09. LNCS 5771.&lt;br /&gt;
&lt;br /&gt;
* [BJS08] F. Blanqui, J.-P. Jouannaud and P.-Y. Strub. &#039;&#039;From formal proofs to mathematical proofs: a safe, incremental way for building in first-order decision procedures&#039;&#039;. TCS&#039;08. IFIP 273.&lt;br /&gt;
&lt;br /&gt;
* [BHW07] F. Blanqui, Thérèse Hardin and Pierre Weis. &#039;&#039;On the Implementation of Construction Functions for Non-free Concrete Data Types&#039;&#039;. ESOP 2007: 95-109.&lt;br /&gt;
&lt;br /&gt;
==== Emmanuel Chailloux (LIP6, Paris) ====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Age 51,  full professor at the University &lt;br /&gt;
Pierre et Marie Curie ([http://www.upmc.fr UPMC - Paris 6]) in Paris France, &lt;br /&gt;
and since October 2006  researcher at the &lt;br /&gt;
[http://www.lip6.fr LIP6] computer science laboratory (UMR 7606), &lt;br /&gt;
in the &amp;quot;Algorithms, Programs and Resolution&amp;quot; team ([http://www-apr.lip6.fr APR]).&lt;br /&gt;
&lt;br /&gt;
His research work is related to design and implementation of programming languages : &lt;br /&gt;
* semantics, &lt;br /&gt;
* types systems, &lt;br /&gt;
* runtime implementation, &lt;br /&gt;
* multicores. &lt;br /&gt;
Most of the recent publications relate to safety-critical software development.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Recent publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[VWC-2011] Vaugon B., Wang P., Chailloux E. &#039;&#039; Les microcontrôleurs&lt;br /&gt;
PIC programmés en Objective Caml&#039;&#039;. Journées des Langages Applicatifs&lt;br /&gt;
(JFLA&#039;2011), janvier 2011.&lt;br /&gt;
&lt;br /&gt;
[WJC-2010] Wang P., Jonquet A., Chailloux E. &#039;&#039;Non-Intrusive&lt;br /&gt;
Structural Coverage for Objective Caml&#039;&#039;.  5th Workshop on Bytecode&lt;br /&gt;
Semantics, Verification, Analysis and Transformation (Bytecode), 2010.&lt;br /&gt;
&lt;br /&gt;
[PAMCCWMC-2009] Pagano B., Andrieu O., Moniot T., Canou B., Chailloux&lt;br /&gt;
E., Wang P., Manoury P., Colaço J.-L. &#039;&#039;Experience Report: Using&lt;br /&gt;
Objective Caml to develop safety-critical embedded tool in a&lt;br /&gt;
certificaiton framework&#039;&#039;.  International Conference of Functional&lt;br /&gt;
Programming (ICFP&#039;09), 2009.&lt;br /&gt;
&lt;br /&gt;
[CBC-2008] Canou B., Balat V., Chailloux E. &#039;&#039;O&#039;Browser : Objective&lt;br /&gt;
Caml on browsers&#039;&#039;. The 2008 ACM SIGPLAN Workshop on ML, 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;HIRONDML: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 2008, 55--69.&lt;br /&gt;
&lt;br /&gt;
[PACCCMW-2008] Pagano B., Andrieu O., Canou B., Chailloux E., Colaço J.-L., Moniot T., Wang P. &lt;br /&gt;
&#039;&#039;Certified development tools implementation in objective caml.&#039;&#039;  &lt;br /&gt;
International Symposium on Practical Aspects of Declarative Languages (PADL 08), 2008.&lt;br /&gt;
&lt;br /&gt;
[CRV-2008] Chailloux E., Ravet V., Verlaguet J. &#039;&#039;Hirondml: Fair&lt;br /&gt;
Threads Migrations for Objective Caml&#039;&#039;. Parallel Processing Letters&lt;br /&gt;
18, 1 (2008) 55-69&lt;br /&gt;
&lt;br /&gt;
[HMC-2007] Henry G., Mauny M., Chailloux E. &#039;&#039;Typer la désérialisation&lt;br /&gt;
sans sérialiser les types&#039;&#039;. Technique et Science Informatiques 26, 9&lt;br /&gt;
(2007) 1067-1090.&lt;br /&gt;
&lt;br /&gt;
[CM-2006] Chailloux E., Mauny M. &#039;&#039;Programmation fonctionnelle&#039;&#039;.&lt;br /&gt;
Encyclopédie de l&#039;informatique et des systèmes d&#039;information (2006)&lt;br /&gt;
1016--1027.&lt;br /&gt;
&lt;br /&gt;
==== Tom Hirshowitz (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
34 ans, CR CNRS (informatique) , LAMA&lt;br /&gt;
&lt;br /&gt;
* 2007         CR CNRS au LAMA (UMR 5127) à Chambéry&lt;br /&gt;
* 2004-2007    CR CNRS au LIP (UMR5668) à Lyon&lt;br /&gt;
* 2003-2004    ATER, équipe Plume, LIP, ENS Lyon&lt;br /&gt;
* 2000-2003    Doctorat (dir.: X. Leroy, INRIA Rocquencourt, projet Cristal)&lt;br /&gt;
* 1999-2000    DEA à Paris 7&lt;br /&gt;
* 1996-2000    Ecole Nationale des Ponts et Chaussées&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;10 publications dans des revues et conférences internationales&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;publications choisies&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
# T. Hirschowitz, X. Leroy, and J. B. Wells. Compilation of extended recursion in call-by-value functional languages, PPDP 2003. Version journal dans Higher-Order and Symbolic Computation 22-1. 2009.&lt;br /&gt;
# R. Garner, T. Hirschowitz, and A. Pardon. Variable Binding, Symmetric Monoidal Closed Theories and Bigraphs. CONCUR&#039;09. 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. Contraction-free Proofs and Finitary Games for Linear Logic. MFPS, 2009.&lt;br /&gt;
# A. Hirschowitz, M. Hirschowitz, T. Hirschowitz. A Theory for Game Theories. FSTTCS, 2007.&lt;br /&gt;
# T. Hirschowitz, X. Leroy. Mixin Modules in a Call-by-Value Setting, ESOP, 2002, journal version in ACM Transactions on Programming Languages and Systems, 2005.&lt;br /&gt;
&lt;br /&gt;
==== Pierre Hyvernat (LAMA, Chambéry) ====&lt;br /&gt;
&lt;br /&gt;
Age 30, &amp;quot;maître de conférences&amp;quot; at the Université de Savoie (in Chambéry) since September 2006, member of the [http://www.lama.univ-savoie.fr LAMA].&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2005, under the supervision of Thierry Coquand (Chalmers, Göteborg, Sweden) and Thomas Ehrhard (at the time, IML, Luminy, Marseille, France)&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include&lt;br /&gt;
* denotational semantics,&lt;br /&gt;
* type theory and constructive mathematics.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [Hyv10b] &#039;&#039;The Size-Change Termination Principle for Constructor Based Languages&#039;&#039; (hal-00547440, submitted)&lt;br /&gt;
&lt;br /&gt;
* [HHy06] with P. Hancock: &#039;&#039;Programming Interfaces and Basic Topology&#039;&#039;. &amp;quot;Annals of Pure and Applied Logic&amp;quot;, volume 137, January 2006,&lt;br /&gt;
&lt;br /&gt;
* [Hyv05] &#039;&#039;Synchronous Games, Simulations and lambda-calculus&#039;&#039;, proceedings of the &amp;quot;GaLoP&amp;quot; workshop, ETAPS 2005. (journal version submitted to Annals of Pure and Applied Logic),&lt;br /&gt;
&lt;br /&gt;
* [Hyv04] &#039;&#039;Predicate Transformers and Linear Logic: yet another Denotational Model&#039;&#039;, Lecture Notes in Computer Science, vol. 3210, September 2004.&lt;br /&gt;
&lt;br /&gt;
==== Alexandre Miquel (PPS, Paris 7) ====&lt;br /&gt;
&lt;br /&gt;
Age 37, &amp;quot;maître de conférences&amp;quot; at the Université Paris-Diderot (Paris 7) since September 2003, member of [http://www.pps.jussieu.fr/ PPS]. Currently CNRS research associate (&amp;quot;délégation&amp;quot;) in the Plume team at the LIP (ENS Lyon) since September 2008.&lt;br /&gt;
&lt;br /&gt;
He obtained his PhD thesis in December 2001, under the supervision of Hugo Herbelin (INRIA/LIX) in the Coq team (now TypiCal).&lt;br /&gt;
&lt;br /&gt;
From October 2001 to August 2002 he was postdoc in the Chalmers Institute of Technology (Göetborg, Sweden) under the supervision of Thierry Coquand, and from September 2002 to August 2003 he was &amp;quot;ATER&amp;quot; at the LRI (Orsay).&lt;br /&gt;
&lt;br /&gt;
He is a specialist of the models of type theory (especially the calculus of constructions) and of the correspondence between set theory and type theory. His research interests also include:&lt;br /&gt;
* logic, proof-theory, rewriting,&lt;br /&gt;
* denotational semantics (set- and domain-theoretic),&lt;br /&gt;
* realizability in classical logic.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Selected publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
His most significant publications are:&lt;br /&gt;
&lt;br /&gt;
* [Miq07] &#039;&#039;Classical program extraction in the calculus of constructions&#039;&#039; (CSL&#039;07),&lt;br /&gt;
&lt;br /&gt;
* [Miq06] with A. Arbiser and A. Ríos. &#039;&#039;A lambda-calculus with constructors&#039;&#039; (RTA&#039;06),&lt;br /&gt;
&lt;br /&gt;
* [Miq04] &#039;&#039;Lambda-Z: Zermelo&#039;s Set Theory as a PTS with 4 Sorts&#039;&#039; (TYPES&#039;04),&lt;br /&gt;
&lt;br /&gt;
* [Miq03] &#039;&#039;A Strongly Normalising Curry-Howard Correspondence for IZF Set Theory&#039;&#039; (CSL&#039;03),&lt;br /&gt;
&lt;br /&gt;
* [Miq00] &#039;&#039;A Model for Impredicative Type Systems with Universes, Intersection Types and Subtyping&#039;&#039; (LICS&#039;00).&lt;br /&gt;
&lt;br /&gt;
==== Christophe Mouilleron (LIP, ENS de Lyon) ====&lt;br /&gt;
&lt;br /&gt;
Age 26, PhD student in the Arenaire team at the LIP (ENS de Lyon) since September 2008. He works under the supervision of Claude-Pierre Jeannerod (INRIA/LIP) and Gilles Villard (CNRS/LIP).&lt;br /&gt;
&lt;br /&gt;
His research interests relevant to PML include :&lt;br /&gt;
* computer arithmetic,&lt;br /&gt;
* code generation,&lt;br /&gt;
* formal proof of numerical properties in programs.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Publications&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
* [MouRev10] C. Mouilleron and G. Revy. &#039;&#039;Automatic Generation of Fast and Certified Code for Polynomial Evaluation.&#039;&#039; (submitted, available as ensl-00531721)&lt;br /&gt;
&lt;br /&gt;
* [JeaMou10] C.-P. Jeannerod and C. Mouilleron. &#039;&#039;Computing Specified Generators of Structured Matrix Inverses.&#039;&#039; (ISSAC&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [BJJK+10] C. Bertin, C.-P. Jeannerod, J. Jourdan-Lu, H. Knochel, C. Monat, C. Mouilleron, J.-M. Muller, and G. Revy. &#039;&#039;Techniques and tools for implementing IEEE 754 floating-point arithmetic on VLIW integer processors.&#039;&#039; (PASCO&#039;10)&lt;br /&gt;
&lt;br /&gt;
* [LTdD+10] V. Lefèvre, P. Théveny, F. de Dinechin, C.-P. Jeannerod, C. Mouilleron, D. Pfannholzer, and N. Revol. &#039;&#039;LEMA : Towards a Language for Reliable Arithmetic.&#039;&#039; (PLMMS&#039;10)&lt;br /&gt;
&lt;br /&gt;
===Relevant publications by non participants to the project ===&lt;br /&gt;
&lt;br /&gt;
Here are some publication or resources of interest for the project:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Laguage design and theory:&#039;&#039;&#039;&lt;br /&gt;
* [SOW97] Martin Sulzmann, Martin Odersky, Martin Wehr, &#039;&#039;Type inference with constrained types&#039;&#039;, TAPOS, 1997.&lt;br /&gt;
* [HW04] Christian Haack and J. B. Wells, &#039;&#039;Type error slicing in implicitly typed higher-order languages&#039;&#039;, Sci. Comput. Programming, 50:189-224, 2004.&lt;br /&gt;
* [Ruy06] Frédéric Ruyer, &#039;&#039;Preuves, types et sous-type&#039;&#039;, phd 2006 directed by C. Raffalli.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Termination:&#039;&#039;&#039;&lt;br /&gt;
* [LJ01] Lee, Jones, et al. &#039;&#039;The size-change principle for program termination&#039;&#039; - ACM SIGPLAN Notices - 2001&lt;br /&gt;
* [Abel04] Andreas Abel, &#039;&#039;Termination Checking with Types&#039;&#039; ,Special Issue: Fixed Points in Computer Science (FICS&#039;03 and RAIR&#039;04)&lt;br /&gt;
* [Bar04]   G. Barthe, M. J. Frade  and E. Giménez, L. Pinto and T. Uustalu, &#039;&#039;Type-Based Termination of Recursive Definitions&#039;&#039;, 2004, Mathematical Structures in Computer Science.&lt;br /&gt;
* [Gie06] J. Giesl, S. Swiderski, P. Schneider-Kamp, and R. Thiemann &#039;&#039;Automated Termination Analysis for Haskell: From Term Rewriting to Programming Languages&#039;&#039;, Proceedings of the 17th International Conference on Rewriting Techniques and Applications (RTA-06), Lecture Notes in Computer Science 4098.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;the Clean language:&#039;&#039;&#039;&lt;br /&gt;
* [AGR92] Peter Achten, John van Groningen and Rinus Plasmeijer (1992). &#039;&#039;High-level specification of I/O in functional languages&#039;&#039;, Proc. of the Glasgow workshop on Functional programming, ed. J. Launchbury and P. Sansom, Ayr, Scotland, Springer-Verlag, Workshops in Computing, pp. 1-17.&lt;br /&gt;
* [AcP95] Peter Achten and Rinus Plasmeijer (1995). &#039;&#039;The Ins and Outs of CONCURRENT CLEAN I/O&#039;&#039;, Journal of Functional Programming, 5, 1, pp. 81-110.&lt;br /&gt;
* [AcP97] Peter Achten and Rinus Plasmeijer (1997). &#039;&#039;Interactive Functional Objects in CLEAN&#039;&#039;, Proc. of the 1997 Workshop on the Implementation of Functional Languages (IFL&#039;97), ed. K. Hammond Davie, T., and Clack, C., St.Andrews, Scotland,&lt;br /&gt;
* [VPA07] Edsko de Vries, Rinus Plasmeijer, and David M. Abrahamson, &#039;&#039;Uniqueness Typing Simplified, by Edsko de Vries&#039;&#039;,&lt;br /&gt;
* [http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf the language report] by Rinus Plasmeijer and Marko van Eekelen,&lt;br /&gt;
* [http://clean.cs.ru.nl/ the language homepage].&lt;br /&gt;
&lt;br /&gt;
===Involvement of project participants to other grants, contracts, etc …===&lt;br /&gt;
&lt;br /&gt;
* Frederic Blanqui is involved in the Sino-French ANR SIVES 2009-2011 on SImulation and Verification based platform for developing Embedded Systems.&lt;br /&gt;
* Emmanuel Chailloux is member of the ANR PWD (&amp;quot;Programmation du Web Diffus&amp;quot;), whose leader is Manuel Serrano (Inria), and the FUI [http://opengpu.net/ OpenGPU project].  &lt;br /&gt;
* Tom Hishowitz is involved in the ANR PiCoq the ANR proposals RÉCRÉ and CATHRE.&lt;br /&gt;
* Pierre Hyvernat is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Alexandre Miquel is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
* Christophe Raffalli is involved in the ANR proposal RÉCRÉ.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Remark: the interaction with PML and RÉCRÉ is natural because the proof technics used for ensuring some of the properties of the language PML is réalizability which is one of the théma of the ANR proposal RÉCRÉ.&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Mise_en_ligne_des_calendriers&amp;diff=4551</id>
		<title>Mise en ligne des calendriers</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Mise_en_ligne_des_calendriers&amp;diff=4551"/>
		<updated>2009-11-27T07:52:41Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Autres calendriers */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Vous pouvez vous abonner aux calendriers suivants : &lt;br /&gt;
* votre agenda planète&lt;br /&gt;
* calendrier séminaires&lt;br /&gt;
* calendrier labo (évènements importants du labo : deadline ANR par exemple)&lt;br /&gt;
&lt;br /&gt;
Pour cela, vous devez configurer un client sur votre machine (voir ci-dessous).&lt;br /&gt;
Nous avons testé différents clients et nous recommandons le client Mulberry qui existe sur toutes les plateformes (Linux, Windows et Mac). Les habitués du client Ical sous Mac peuvent aussi le garder. &lt;br /&gt;
Dans un calendrier coexistent les notions d&#039;évènements (bien gérés par mulberry) et la notion de tâches (bien pris en charge pour les calendriers personnels mais très mal gérés par la plupart des clients pour les calendriers partagés (celui du laboratoire par exemple), en gros la communication avec le serveur ne se fait que partiellement voire pas du tout).&lt;br /&gt;
&lt;br /&gt;
Pour le calendrier planète : il y a une petite manipulation que Christophe ou Céline doivent faire pour chaque personne.&lt;br /&gt;
&lt;br /&gt;
Vous pouvez aussi stocker vos agendas personnels sur le serveur du labo (voir fin de la doc), ce qui permet de les voir depuis plusieurs postes de travail (y compris i-phone et sans doute Androïd phone).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Calendrier planète ==&lt;br /&gt;
&lt;br /&gt;
On peut depuis mi-novembre 2009 avoir accès au calendrier planète !&lt;br /&gt;
&lt;br /&gt;
Il faut donner à Christophe Raffalli ou Céline Acary-Robert votre nom ou pour ceux qui ont des homonymes qui enseignent à UdS, une chaine de caractères permettant de trouver votre agenda dans planète. Une fois que l&#039;on a mis en place l&#039;import du calendrier, l&#039;URL du calendrier est &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/ADE/calendar_lachainederecherche.ics&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Exemple, pour Stéphane Simon, la chaîne &amp;quot;simon s&amp;quot; lui permet de trouver son agenda et l&#039;URL est (il faut parfois remplacer les espaces par &#039;&#039;&#039;%20&#039;&#039;&#039;).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/ADE/calendar_simon%20s.ics&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Le calendrier est mis à jour une fois par nuit à partir du serveur planète (si celui-ci n&#039;est pas en panne).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Calendrier séminaires et laboratoire en lecture ==&lt;br /&gt;
&lt;br /&gt;
Un serveur Caldav a été installé sur le serveur du labo. Il permet de gérer des calendriers et de les afficher sur une page web (voir le calendrier du labo [http://www.lama.univ-savoie.fr/index.php?frame=1&amp;amp;titre=Calendrier%20du%20LAMA&amp;amp;height=1200px&amp;amp;page=http://www.lama.univ-savoie.fr/phpicalendar ici])  ou affiché dans un client sur une machine perso.&lt;br /&gt;
&lt;br /&gt;
=== Calendrier séminaires ===&lt;br /&gt;
&lt;br /&gt;
Il s&#039;agit ici d&#039;afficher dans le client choisi un calendrier publié sur le web au format ics. Il faut donc créer un &#039;&#039;&#039;web calendar&#039;&#039;&#039; qui a pour URL &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/icalsem.php&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
avec les options suivantes :&lt;br /&gt;
&lt;br /&gt;
* begin=2003:01:01 (par défaut c&#039;est 100 jours en arrière)&lt;br /&gt;
* equipes=lama,edp,logique,geometrie (au choix, par défaut c&#039;est tous les séminaires qui sont affichés)&lt;br /&gt;
&lt;br /&gt;
Exemple, si vous voulez juste le séminaire de géométrie et les sémaire la labo, il faut mettre:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/icalsem.php?equipes=lama,geometrie&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Calendrier laboratoire ===&lt;br /&gt;
&lt;br /&gt;
Un calendrier du laboratoire a été mis en place. Il contiendra des évènements d&#039;intérêt général (deadline ANR, conseil d&#039;UFR, ...)&lt;br /&gt;
&lt;br /&gt;
L&#039;url est  &#039;&#039;&#039;&amp;lt;nowiki&amp;gt;https://www.lama.univ-savoie.fr/cal/public.php/labo-resources/public&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039; (attention, c&#039;est du https)&lt;br /&gt;
&lt;br /&gt;
=== Calendrier séminaire et labo sur le Web sans client iCal ou autre ===&lt;br /&gt;
&lt;br /&gt;
Il y a [http://www.lama.univ-savoie.fr/index.php?frame=1&amp;amp;titre=Calendrier%20du%20LAMA&amp;amp;height=1200px&amp;amp;page=http://www.lama.univ-savoie.fr/phpicalendar là un petit calendrier visible sur le site web directement]. IL y a aussi un lien sur ce calendrier à&lt;br /&gt;
partir des [https://www.lama.univ-savoie.fr//index.php?use=interne&amp;amp;&amp;amp;lang=fr pages internes du labo]&lt;br /&gt;
&lt;br /&gt;
=== Autres calendriers ===&lt;br /&gt;
&lt;br /&gt;
Calendrier commun avec Plume (le séminaire LIMD-Plume y est dupliqué, mais il y a aussi d&#039;autres évènements spécifiques à Plume) : &lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.google.com/calendar/ical/qe60dn1sjrfk8c1fji62rvi7mo%40group.calendar.google.com/public/basic.ics&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Calendrier du groupe de lecture Catégories :&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/cal/public.php/cat-res/public/&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Calendrier labo et/ou calendrier personnel en lecture/écriture ==&lt;br /&gt;
&lt;br /&gt;
Vous pouvez stocker un calendrier sur le serveur du labo (grâce au serveur CALDAV qui y est installé) afin de pouvoir y accéder de partout ...Ces calendriers peuvent être affichés dans un client sur une ou plusieurs machines. &lt;br /&gt;
Pour cela, il faut demander la création d&#039;un compte à un administrateur (Christophe Raffalli, Frédéric Mangolte, Céline Acary-Robert, Claudia Billat) et configurer un client calendrier sur votre machine. &lt;br /&gt;
Une fois votre compte CALDAV crée sur le serveur, vous avez accès à un calendrier personnel et au calendrier du laboratoire si vous avez le droit. Seul les clients mulberry (linux, windows et OSX) et iCal (OSX) marchent. Sunbird devrait marcher bientôt ...&lt;br /&gt;
&lt;br /&gt;
Sur mulberry, il faut créer un compte de type &#039;&#039;&#039;CalDav&#039;&#039;&#039; et renseigner le nom du serveur &#039;&#039;www.lama.univ-savoie.fr&#039;&#039;, le chemin &#039;&#039;&#039;/cal/&#039;&#039;&#039; et ensuite son login (le mot de passe est demandé pour authentification sur le serveur). Il faut aussi indiquer que l&#039;on utilise un accès crypté. &lt;br /&gt;
&lt;br /&gt;
Pour iCal, il faut indiquer l&#039;URL suivante (avec parfois des problèmes pour accepter le certificat SSL du serveur) :&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;https://www.lama.univ-savoie.fr:443/cal/caldav.php/votre_login/home/&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Bien mettre le &#039;/&#039; à la fin.&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Le mieux est de demander à Christophe ou Céline ...&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Mise_en_ligne_des_calendriers&amp;diff=4550</id>
		<title>Mise en ligne des calendriers</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Mise_en_ligne_des_calendriers&amp;diff=4550"/>
		<updated>2009-11-27T07:52:14Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Calendrier séminaires et laboratoire en lecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Vous pouvez vous abonner aux calendriers suivants : &lt;br /&gt;
* votre agenda planète&lt;br /&gt;
* calendrier séminaires&lt;br /&gt;
* calendrier labo (évènements importants du labo : deadline ANR par exemple)&lt;br /&gt;
&lt;br /&gt;
Pour cela, vous devez configurer un client sur votre machine (voir ci-dessous).&lt;br /&gt;
Nous avons testé différents clients et nous recommandons le client Mulberry qui existe sur toutes les plateformes (Linux, Windows et Mac). Les habitués du client Ical sous Mac peuvent aussi le garder. &lt;br /&gt;
Dans un calendrier coexistent les notions d&#039;évènements (bien gérés par mulberry) et la notion de tâches (bien pris en charge pour les calendriers personnels mais très mal gérés par la plupart des clients pour les calendriers partagés (celui du laboratoire par exemple), en gros la communication avec le serveur ne se fait que partiellement voire pas du tout).&lt;br /&gt;
&lt;br /&gt;
Pour le calendrier planète : il y a une petite manipulation que Christophe ou Céline doivent faire pour chaque personne.&lt;br /&gt;
&lt;br /&gt;
Vous pouvez aussi stocker vos agendas personnels sur le serveur du labo (voir fin de la doc), ce qui permet de les voir depuis plusieurs postes de travail (y compris i-phone et sans doute Androïd phone).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Calendrier planète ==&lt;br /&gt;
&lt;br /&gt;
On peut depuis mi-novembre 2009 avoir accès au calendrier planète !&lt;br /&gt;
&lt;br /&gt;
Il faut donner à Christophe Raffalli ou Céline Acary-Robert votre nom ou pour ceux qui ont des homonymes qui enseignent à UdS, une chaine de caractères permettant de trouver votre agenda dans planète. Une fois que l&#039;on a mis en place l&#039;import du calendrier, l&#039;URL du calendrier est &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/ADE/calendar_lachainederecherche.ics&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Exemple, pour Stéphane Simon, la chaîne &amp;quot;simon s&amp;quot; lui permet de trouver son agenda et l&#039;URL est (il faut parfois remplacer les espaces par &#039;&#039;&#039;%20&#039;&#039;&#039;).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/ADE/calendar_simon%20s.ics&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Le calendrier est mis à jour une fois par nuit à partir du serveur planète (si celui-ci n&#039;est pas en panne).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Calendrier séminaires et laboratoire en lecture ==&lt;br /&gt;
&lt;br /&gt;
Un serveur Caldav a été installé sur le serveur du labo. Il permet de gérer des calendriers et de les afficher sur une page web (voir le calendrier du labo [http://www.lama.univ-savoie.fr/index.php?frame=1&amp;amp;titre=Calendrier%20du%20LAMA&amp;amp;height=1200px&amp;amp;page=http://www.lama.univ-savoie.fr/phpicalendar ici])  ou affiché dans un client sur une machine perso.&lt;br /&gt;
&lt;br /&gt;
=== Calendrier séminaires ===&lt;br /&gt;
&lt;br /&gt;
Il s&#039;agit ici d&#039;afficher dans le client choisi un calendrier publié sur le web au format ics. Il faut donc créer un &#039;&#039;&#039;web calendar&#039;&#039;&#039; qui a pour URL &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/icalsem.php&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
avec les options suivantes :&lt;br /&gt;
&lt;br /&gt;
* begin=2003:01:01 (par défaut c&#039;est 100 jours en arrière)&lt;br /&gt;
* equipes=lama,edp,logique,geometrie (au choix, par défaut c&#039;est tous les séminaires qui sont affichés)&lt;br /&gt;
&lt;br /&gt;
Exemple, si vous voulez juste le séminaire de géométrie et les sémaire la labo, il faut mettre:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/icalsem.php?equipes=lama,geometrie&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Calendrier laboratoire ===&lt;br /&gt;
&lt;br /&gt;
Un calendrier du laboratoire a été mis en place. Il contiendra des évènements d&#039;intérêt général (deadline ANR, conseil d&#039;UFR, ...)&lt;br /&gt;
&lt;br /&gt;
L&#039;url est  &#039;&#039;&#039;&amp;lt;nowiki&amp;gt;https://www.lama.univ-savoie.fr/cal/public.php/labo-resources/public&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039; (attention, c&#039;est du https)&lt;br /&gt;
&lt;br /&gt;
=== Calendrier séminaire et labo sur le Web sans client iCal ou autre ===&lt;br /&gt;
&lt;br /&gt;
Il y a [http://www.lama.univ-savoie.fr/index.php?frame=1&amp;amp;titre=Calendrier%20du%20LAMA&amp;amp;height=1200px&amp;amp;page=http://www.lama.univ-savoie.fr/phpicalendar là un petit calendrier visible sur le site web directement]. IL y a aussi un lien sur ce calendrier à&lt;br /&gt;
partir des [https://www.lama.univ-savoie.fr//index.php?use=interne&amp;amp;&amp;amp;lang=fr pages internes du labo]&lt;br /&gt;
&lt;br /&gt;
=== Autres calendriers ===&lt;br /&gt;
&lt;br /&gt;
Calendrier commun avec Plume (le séminaire LIMD-Plume y est dupliqué, mais il y a aussi d&#039;autres évènements spécifiques à Plume) : &lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.google.com/calendar/ical/qe60dn1sjrfk8c1fji62rvi7mo%40group.calendar.google.com/public/basic.ics&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
Calendrier du groupe de lecture Catégories :&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/cal/public.php/cat-res/public&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
== Calendrier labo et/ou calendrier personnel en lecture/écriture ==&lt;br /&gt;
&lt;br /&gt;
Vous pouvez stocker un calendrier sur le serveur du labo (grâce au serveur CALDAV qui y est installé) afin de pouvoir y accéder de partout ...Ces calendriers peuvent être affichés dans un client sur une ou plusieurs machines. &lt;br /&gt;
Pour cela, il faut demander la création d&#039;un compte à un administrateur (Christophe Raffalli, Frédéric Mangolte, Céline Acary-Robert, Claudia Billat) et configurer un client calendrier sur votre machine. &lt;br /&gt;
Une fois votre compte CALDAV crée sur le serveur, vous avez accès à un calendrier personnel et au calendrier du laboratoire si vous avez le droit. Seul les clients mulberry (linux, windows et OSX) et iCal (OSX) marchent. Sunbird devrait marcher bientôt ...&lt;br /&gt;
&lt;br /&gt;
Sur mulberry, il faut créer un compte de type &#039;&#039;&#039;CalDav&#039;&#039;&#039; et renseigner le nom du serveur &#039;&#039;www.lama.univ-savoie.fr&#039;&#039;, le chemin &#039;&#039;&#039;/cal/&#039;&#039;&#039; et ensuite son login (le mot de passe est demandé pour authentification sur le serveur). Il faut aussi indiquer que l&#039;on utilise un accès crypté. &lt;br /&gt;
&lt;br /&gt;
Pour iCal, il faut indiquer l&#039;URL suivante (avec parfois des problèmes pour accepter le certificat SSL du serveur) :&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;https://www.lama.univ-savoie.fr:443/cal/caldav.php/votre_login/home/&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Bien mettre le &#039;/&#039; à la fin.&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Le mieux est de demander à Christophe ou Céline ...&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Mise_en_ligne_des_calendriers&amp;diff=4534</id>
		<title>Mise en ligne des calendriers</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Mise_en_ligne_des_calendriers&amp;diff=4534"/>
		<updated>2009-11-20T11:12:52Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Introduction ==&lt;br /&gt;
&lt;br /&gt;
Vous pouvez vous abonner aux calendriers suivants : &lt;br /&gt;
* votre agenda planète&lt;br /&gt;
* calendrier séminaires&lt;br /&gt;
* calendrier labo (évènements importants du labo : deadline ANR par exemple)&lt;br /&gt;
&lt;br /&gt;
Pour cela, vous devez configurer un client sur votre machine (voir ci-dessous).&lt;br /&gt;
Nous avons testé différents clients et nous recommandons le client Mulberry qui existe sur toutes les plateformes (Linux, Windows et Mac). Les habitués du client Ical sous Mac peuvent aussi le garder. &lt;br /&gt;
Dans un calendrier coexistent les notions d&#039;évènements (bien gérés par mulberry) et la notion de tâches (bien pris en charge pour les calendriers personnels mais très mal gérés par la plupart des clients pour les calendriers partagés (celui du laboratoire par exemple), en gros la communication avec le serveur ne se fait que partiellement voire pas du tout).&lt;br /&gt;
&lt;br /&gt;
Pour le calendrier planète : il y a une petite manipulation que Christophe ou Céline doivent faire pour chaque personne.&lt;br /&gt;
&lt;br /&gt;
Vous pouvez aussi stocker vos agendas personnels sur le serveur du labo (voir fin de la doc), ce qui permet de les voir depuis plusieurs postes de travail (y compris i-phone et sans doute Androïd phone).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Calendrier planète ==&lt;br /&gt;
&lt;br /&gt;
On peut depuis mi-novembre 2009 avoir accès au calendrier planète !&lt;br /&gt;
&lt;br /&gt;
Il faut donner à Christophe Raffalli ou Céline Acary-Robert votre nom ou pour ceux qui ont des homonymes qui enseignent à UdS, une chaine de caractères permettant de trouver votre agenda dans planète. Une fois que l&#039;on a mis en place l&#039;import du calendrier, l&#039;URL du calendrier est &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/ADE/calendar_lachainederecherche.ics&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Exemple, pour Stéphane Simon, la chaîne &amp;quot;simon s&amp;quot; lui permet de trouver son agenda et l&#039;URL est (il faut parfois remplacer les espaces par &#039;&#039;&#039;%20&#039;&#039;&#039;).&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/ADE/calendar_simon%20s.ics&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Le calendrier est mis à jour une fois par nuit à partir du serveur planète (si celui-ci n&#039;est pas en panne).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Calendrier séminaires et laboratoire en lecture ==&lt;br /&gt;
&lt;br /&gt;
Un serveur Caldav a été installé sur le serveur du labo. Il permet de gérer des calendriers et de les afficher sur une page web (voir le calendrier du labo [http://www.lama.univ-savoie.fr/index.php?frame=1&amp;amp;titre=Calendrier%20du%20LAMA&amp;amp;height=1200px&amp;amp;page=http://www.lama.univ-savoie.fr/phpicalendar ici])  ou affiché dans un client sur une machine perso.&lt;br /&gt;
&lt;br /&gt;
=== Calendrier séminaires ===&lt;br /&gt;
&lt;br /&gt;
Il s&#039;agit ici d&#039;afficher dans le client choisi un calendrier publié sur le web au format ics. Il faut donc créer un &#039;&#039;&#039;web calendar&#039;&#039;&#039; qui a pour URL &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/icalsem.php&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
avec les options suivantes :&lt;br /&gt;
&lt;br /&gt;
* begin=2003:01:01 (par défaut c&#039;est 100 jours en arrière)&lt;br /&gt;
* equipes=lama,edp,logique,geometrie (au choix, par défaut c&#039;est tous les séminaires qui sont affichés)&lt;br /&gt;
&lt;br /&gt;
Exemple, si vous voulez juste le séminaire de géométrie et les sémaire la labo, il faut mettre:&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;http://www.lama.univ-savoie.fr/icalsem.php?equipes=lama,geometrie&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Calendrier laboratoire ===&lt;br /&gt;
&lt;br /&gt;
Un calendrier du laboratoire a été mis en place. Il contiendra des évènements d&#039;intérêt général (deadline ANR, conseil d&#039;UFR, ...)&lt;br /&gt;
&lt;br /&gt;
L&#039;url est  &#039;&#039;&#039;&amp;lt;nowiki&amp;gt;https://www.lama.univ-savoie.fr/cal/public.php/labo-resources/public&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039; (attention, c&#039;est du https)&lt;br /&gt;
&lt;br /&gt;
=== Calendrier séminaire et labo sur le Web sans client iCal ou autre ===&lt;br /&gt;
&lt;br /&gt;
Il y a [http://www.lama.univ-savoie.fr/index.php?frame=1&amp;amp;titre=Calendrier%20du%20LAMA&amp;amp;height=1200px&amp;amp;page=http://www.lama.univ-savoie.fr/phpicalendar là un petit calendrier visible sur le site web directement]. IL y a aussi un lien sur ce calendrier à&lt;br /&gt;
partir des [https://www.lama.univ-savoie.fr//index.php?use=interne&amp;amp;&amp;amp;lang=fr pages internes du labo]&lt;br /&gt;
&lt;br /&gt;
== Calendrier labo et/ou calendrier personnel en lecture/écriture ==&lt;br /&gt;
&lt;br /&gt;
Vous pouvez stocker un calendrier sur le serveur du labo (grâce au serveur CALDAV qui y est installé) afin de pouvoir y accéder de partout ...Ces calendriers peuvent être affichés dans un client sur une ou plusieurs machines. &lt;br /&gt;
Pour cela, il faut demander la création d&#039;un compte à un administrateur (Christophe Raffalli, Frédéric Mangolte, Céline Acary-Robert, Claudia Billat) et configurer un client calendrier sur votre machine. &lt;br /&gt;
Une fois votre compte CALDAV crée sur le serveur, vous avez accès à un calendrier personnel et au calendrier du laboratoire si vous avez le droit. Seul les clients mulberry (linux, windows et OSX) et iCal (OSX) marchent. Sunbird devrait marcher bientôt ...&lt;br /&gt;
&lt;br /&gt;
Sur mulberry, il faut créer un compte de type &#039;&#039;&#039;CalDav&#039;&#039;&#039; et renseigner le nom du serveur &#039;&#039;www.lama.univ-savoie.fr&#039;&#039;, le chemin &#039;&#039;&#039;/cal/&#039;&#039;&#039; et ensuite son login (le mot de passe est demandé pour authentification sur le serveur). Il faut aussi indiquer que l&#039;on utilise un accès crypté. &lt;br /&gt;
&lt;br /&gt;
Pour iCal, il faut indiquer l&#039;URL suivante (avec parfois des problèmes pour accepter le certificat SSL du serveur) :&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;lt;nowiki&amp;gt;https://www.lama.univ-savoie.fr:443/cal/caldav.php/votre_login/home/&amp;lt;/nowiki&amp;gt;&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Bien mettre le &#039;/&#039; à la fin.&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Le mieux est de demander à Christophe ou Céline ...&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4113</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4113"/>
		<updated>2009-03-31T20:55:04Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Presheaves and sheaves */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
* March 4. : monads, adjunctions.&lt;br /&gt;
* March 11. : limits and colimits.&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; from a category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to a category &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, noted &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, is given by:&lt;br /&gt;
* a map which sends every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to an object &amp;lt;math&amp;gt;FA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* a map which sends every morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, to a morphism &amp;lt;math&amp;gt;Ff&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}[FA, FB]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves identities, i.e., &amp;lt;math&amp;gt;F(id_A) = id_{FA}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves composition: &amp;lt;math&amp;gt;F(f \circ g) = F(f) \circ F(g)&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Take a functor &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;f, g, h&amp;lt;/math&amp;gt; three morphisms in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;f&#039; = Ff&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&#039; = Fg&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;h&#039; = Fh&amp;lt;/math&amp;gt;. When &amp;lt;math&amp;gt;h&#039; = f&#039; \circ g&#039;&amp;lt;/math&amp;gt;, can we say something interesting about &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt;?&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
# No, since &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; may not even compose! This is the case when &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; has type &amp;lt;math&amp;gt;A \to B&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;g \colon C \to D&amp;lt;/math&amp;gt;, with &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; collapsing &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; (i.e., &amp;lt;math&amp;gt;FA = FD&amp;lt;/math&amp;gt;).&lt;br /&gt;
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; be the category with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, and exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;. This is a preorder, so &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is monic. Now take &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;, and one extra morphism &amp;lt;math&amp;gt;n \colon \star \to \star&amp;lt;/math&amp;gt;, different from the identity. Because of &amp;lt;math&amp;gt;n \neq id_\star&amp;lt;/math&amp;gt;, yet &amp;lt;math&amp;gt;m \circ n = m \circ id&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is not monic in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;. The functor which sends &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, does not preserve monomorphisms.&lt;br /&gt;
# In general, the answer is (again) no. For monos, take for example the functor &amp;lt;math&amp;gt;\mathcal{C} \to \mathbf{2}&amp;lt;/math&amp;gt; which sends &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; to the identity. Yet, when &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is &#039;&#039;faithful&#039;&#039;, then &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is monic (or epic).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is faithful when, for any two morphisms &amp;lt;math&amp;gt;f, g&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;Ff = Fg&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;f=g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is injective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is full when, for any two objects &amp;lt;math&amp;gt;A, B&amp;lt;/math&amp;gt;, if &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; is a morphism &amp;lt;math&amp;gt;FA \to FB&amp;lt;/math&amp;gt;, then there exists &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;Ff = g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is surjective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; be the functor which sends:&lt;br /&gt;
* every set &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt; to the free group generated by &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* every function &amp;lt;math&amp;gt;f \colon X \to Y&amp;lt;/math&amp;gt; to a group morphism defined by: &amp;lt;math&amp;gt;Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;f\colon X \to Y&amp;lt;/math&amp;gt; be a morphism in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, then &amp;lt;math&amp;gt;Y_A(f)&amp;lt;/math&amp;gt; is expected to be a function from the set &amp;lt;math&amp;gt;\mathcal{C}[Y, A]&amp;lt;/math&amp;gt; to the set &amp;lt;math&amp;gt;\mathcal{C}[X, A]&amp;lt;/math&amp;gt;. We can take, for any morphism &amp;lt;math&amp;gt;m \in \mathcal{C}[Y,A]&amp;lt;/math&amp;gt;: &amp;lt;math&amp;gt;Y_A(f)(m) = m \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This extends &amp;lt;math&amp;gt;Y_A&amp;lt;/math&amp;gt; to a contravariant functor, since &amp;lt;math&amp;gt;Y_A(id_X) = id_{\mathcal{C}[X, A]}&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; be two functors &amp;lt;math&amp;gt;\mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;. A natural transformation &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt; from &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a morphism &amp;lt;math&amp;gt;\alpha_A \colon FA \to GA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt; for every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;,&lt;br /&gt;
* such that, for any morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;Gf \circ \alpha_A = \alpha_B \circ Ff&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Adjunctions and Monads==&lt;br /&gt;
&lt;br /&gt;
===2-categories and their diagrammatic calculus===&lt;br /&gt;
&lt;br /&gt;
This part is just to make the definitions of monads and adjunctions&lt;br /&gt;
easier: we do not give the full details, and only intend to provide a&lt;br /&gt;
few intuitions.&lt;br /&gt;
&lt;br /&gt;
{{Definition | A &#039;&#039;2-category&#039;&#039; is like a category: it has objects and&lt;br /&gt;
morphisms between them. But it also has &#039;&#039;2-cells&#039;&#039;, which are&lt;br /&gt;
&#039;morphisms between morphisms&#039;: &lt;br /&gt;
[[Image:2-cat-1.png|center|A 2-cell]] &lt;br /&gt;
These&lt;br /&gt;
2-cells must compose vertically and horizontally, satisfying the&lt;br /&gt;
&#039;&#039;interchange law&#039;&#039;:&lt;br /&gt;
[[Image:2-cat-inter.png|center|Interchange law]]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
There is a more comfortable representation than the &#039;2-diagrams&#039; above.&lt;br /&gt;
In pictures:&lt;br /&gt;
[[Image:Poincare.png|center|String diagram example]]&lt;br /&gt;
In words, the idea is to consider:&lt;br /&gt;
* objects as background colors, &lt;br /&gt;
* morphisms as vertical frontiers between them, and&lt;br /&gt;
* 2-cells as labelled dots.&lt;br /&gt;
&lt;br /&gt;
Then, both compositions correspond to horizontal and vertical&lt;br /&gt;
juxtaposition, respectively.  For example, the interchange law&lt;br /&gt;
corresponds to the two ways of parsing:&lt;br /&gt;
[[Image:interchange.png|center|Interchange law in a string diagram]]&lt;br /&gt;
&lt;br /&gt;
There are technical subtleties hidden behind this nice diagrammatic&lt;br /&gt;
calculus, but we will stick to bare intuitions for now.&lt;br /&gt;
&lt;br /&gt;
===Cat as a 2-category===&lt;br /&gt;
&lt;br /&gt;
The prime example of a 2-category is of course Cat, the category of (small) categories. It has:&lt;br /&gt;
* objects: small categories,&lt;br /&gt;
* morphisms: functors,&lt;br /&gt;
* 2-cells: natural transformations.&lt;br /&gt;
&lt;br /&gt;
Vertical composition of 2-cells is the obvious notion of composition&lt;br /&gt;
of natural transformations.&lt;br /&gt;
&lt;br /&gt;
Define the horizontal composition:&lt;br /&gt;
[[Image:vert-comp.png|center|Vertical composition]] &lt;br /&gt;
by &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{f&#039; (\alpha_a)} f&#039; (g (a)) &lt;br /&gt;
\xrightarrow{\beta_{g (a)}} g&#039; (g (a)) &amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
or equivalently&lt;br /&gt;
 &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{\beta_{f (a)}} g&#039; (f (a)) &lt;br /&gt;
\xrightarrow{g&#039; (\alpha_a)} g&#039; (g (a)).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
The two coincide by naturality. Observe that what we have actually done is:&lt;br /&gt;
* define &#039;&#039;whiskering&#039;&#039;, i.e., composing with an identity, both to the left and to the right, and &lt;br /&gt;
* observe that the two ways of defining horizontal composition from whiskering coincide.&lt;br /&gt;
This yields an equivalent definition of 2-categories.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Monads==&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;Free&#039;&#039; constructions in algebra: monoid, group, etc&lt;br /&gt;
&lt;br /&gt;
*Definition of a monad&lt;br /&gt;
*Eilenberg-Moore&#039;s category of algebras&lt;br /&gt;
*Kleisli&#039;s category of free algebras&lt;br /&gt;
*The category of resolutions of a monad&lt;br /&gt;
===Adjunctions===&lt;br /&gt;
&lt;br /&gt;
*Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt;&lt;br /&gt;
*Definition with hom-sets&lt;br /&gt;
*Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;&lt;br /&gt;
*Adjunctions in a 2-category&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
*Discussion: any syntax defines the free something&lt;br /&gt;
* The issue of variable binding.&lt;br /&gt;
*Adjunction between partial orders = Galois connection&lt;br /&gt;
*&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic&lt;br /&gt;
*Sets/graphs and categories&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
*Composition&lt;br /&gt;
*Preservation of limits/colimits&lt;br /&gt;
*Freyd&#039;s existence theorem, the locally presentable case&lt;br /&gt;
*Beck&#039;s monadicity theorem&lt;br /&gt;
==Limits and Colimits==&lt;br /&gt;
&lt;br /&gt;
===Limits===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Cartesian product.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Binary product.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The product of X and Y, if it exists, is unique up to isomorphism.&#039;&#039; (with proof)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Set, Grp, Ab, Part.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Preorder, Subset(E), Prop with entailment.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Diagram. Cone. Limit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Limits in Set.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for products, pullbacks, equalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Monos as pullbacks.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The limit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; products and equalizers has &amp;quot;all&amp;quot; limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with a terminal object and all binary products and all equalizers has all finite limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Colimits===&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Cocone. Colimit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Sums in Set, Grp, Ab.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for sums, initial objects, pushouts, coequalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Epis as pushouts.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The colimit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The most general unifier (of two terms) is a coequalizer in the &amp;quot;category of substitutions&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; sums and coequalizers has &amp;quot;all&amp;quot; colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with an initial object and all binary sums and all coequalizers has all finite colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Limits, colimits and adjunctions===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A right adjoint preserves limits. A left adjoint preserves colimits.&#039;&#039; (with proof of existence)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The adjunction between Set and Grp&lt;br /&gt;
&lt;br /&gt;
===Sums and products===&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;distributive&#039;&#039; if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;extensive&#039;&#039; if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; &amp;quot;if..then..else..&amp;quot; from B=1+1 and extensivity.&lt;br /&gt;
 &lt;br /&gt;
==Monoidal categories==&lt;br /&gt;
&lt;br /&gt;
===Definition and graphical calculus===&lt;br /&gt;
&lt;br /&gt;
* Definition&lt;br /&gt;
* Graphical calculus&lt;br /&gt;
* The 2-category of monoidal categories, strong monoidal functors, and monoidal transformations&lt;br /&gt;
* Coherence and its many definitions&lt;br /&gt;
&lt;br /&gt;
===From planar to symmetric monoidal categories===&lt;br /&gt;
&lt;br /&gt;
A teaser for the whole enchilada of variations on monoidal structure.&lt;br /&gt;
&lt;br /&gt;
* Braided &lt;br /&gt;
* Balanced&lt;br /&gt;
* Symmetric&lt;br /&gt;
* Compact closed&lt;br /&gt;
* Traced monoidal categories and the Int/GoI construction&lt;br /&gt;
&lt;br /&gt;
===Monoidal categories for linear logic===&lt;br /&gt;
&lt;br /&gt;
* Linear logic &lt;br /&gt;
** Sequent calculus&lt;br /&gt;
** Intuitionnistic variant&lt;br /&gt;
** Proof nets&lt;br /&gt;
&lt;br /&gt;
* Symmetric monoidal closed categories&lt;br /&gt;
&lt;br /&gt;
* Star-autonomous categories&lt;br /&gt;
** Symmetric monoidal closed category with a dualising object&lt;br /&gt;
** Symmetric monoidal category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with:&lt;br /&gt;
*** a full and faithful contravariant endofunctor &amp;lt;math&amp;gt;\mathcal{C}^{op} \xrightarrow{(-)^*} \mathcal{C} &amp;lt;/math&amp;gt;, and&lt;br /&gt;
*** an isomorphism &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\mathcal{C} (A \otimes B, C^*) \cong \mathcal{C} (A, (B \otimes C)^*).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Trimble-Hughes&#039; free star-autonomous category&lt;br /&gt;
** Split star-autonomy&lt;br /&gt;
** The free star-autonomous category as a category of proof nets&lt;br /&gt;
** Trimble rewiring&lt;br /&gt;
&lt;br /&gt;
===Perspectives===&lt;br /&gt;
&lt;br /&gt;
* Premonoidal categories and side effects&lt;br /&gt;
* Products and coproducts&lt;br /&gt;
* Monoidal 2-categories, monoidal double categories.&lt;br /&gt;
&lt;br /&gt;
==Presheaves and sheaves==&lt;br /&gt;
&lt;br /&gt;
===Yoneda===&lt;br /&gt;
&lt;br /&gt;
*A few presheaf categories &amp;lt;math&amp;gt;\hat{\mathcal{C}} := \mathcal{C}^{op} \to \mathbf{Set}&amp;lt;/math&amp;gt;:&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a graph (no composition): graphs.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a preorder: Kripke-style modal logic.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is an order: presheaves on a topological space.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is free: presheaves on an algebraic theory.&lt;br /&gt;
&lt;br /&gt;
*Representable presheaves &amp;lt;math&amp;gt;yA(B) := \mathcal{C}(B, A)&amp;lt;/math&amp;gt;, and their meaning in each of the examples.&lt;br /&gt;
&lt;br /&gt;
*The Yoneda lemma: for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and presheaf &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt;, there is an isomorphism&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;F (A) \cong \hat{\mathcal{C}} (yA, F),&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
natural in &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
*A consequence: &amp;lt;math&amp;gt;y&amp;lt;/math&amp;gt; is a &#039;full embedding&#039;, or how &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a full subcategory of &amp;lt;math&amp;gt;\hat{\mathcal{C}}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
*Presheaves as a colimit completion&lt;br /&gt;
**The Grothendieck construction, or the category of elements of a presehaf.&lt;br /&gt;
**Example: graphs.&lt;br /&gt;
**Every presheaf is a colimit of representables.&lt;br /&gt;
**Example: graphs.&lt;br /&gt;
**The universal property of &amp;lt;math&amp;gt;y&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Topos structure===&lt;br /&gt;
&lt;br /&gt;
*Limits and colimits in functor categories.&lt;br /&gt;
*Exponentials. If it exists, the exponential &amp;lt;math&amp;gt;G^F&amp;lt;/math&amp;gt; must satisfy, for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;:&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\begin{array}{lcl}&lt;br /&gt;
G^F(A) &amp;amp; \cong &amp;amp; \hat{\mathcal{C}} (yA, G^F) \\&lt;br /&gt;
&amp;amp; \cong &amp;amp; \hat{\mathcal{C}} (yA \times F, G).&lt;br /&gt;
\end{array}&lt;br /&gt;
&amp;lt;/math&amp;gt;&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
Taking this as a definition indeed yields an exponential.&lt;br /&gt;
*Computation of the exponential in &#039;&#039;&#039;Gph&#039;&#039;&#039;.&lt;br /&gt;
*The very special presheaf &amp;lt;math&amp;gt;\Omega&amp;lt;/math&amp;gt;.&lt;br /&gt;
*The isomorphism &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\mathit{Sub}(F) \cong \hat{\mathcal{C}} (F, \Omega). &amp;lt;/math&amp;gt;&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
*The official definition of a subobject classifier and a topos.&lt;br /&gt;
&lt;br /&gt;
===Sheaves===&lt;br /&gt;
&lt;br /&gt;
*Sheaves on a space, a few examples and counterexamples:&lt;br /&gt;
**functions, &lt;br /&gt;
**continuous functions,&lt;br /&gt;
**bounded functions.&lt;br /&gt;
*The &amp;lt;math&amp;gt;(\cdot)^+&amp;lt;/math&amp;gt; construction and its convergence in two steps. The counterexample of constant presheaves.&lt;br /&gt;
*Sheaves on a site. Example of sheaves for the dense topology on an algebraic theory and its coincidence with the double negation topology.&lt;br /&gt;
&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4112</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4112"/>
		<updated>2009-03-31T19:57:31Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Yoneda */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
* March 4. : monads, adjunctions.&lt;br /&gt;
* March 11. : limits and colimits.&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; from a category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to a category &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, noted &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, is given by:&lt;br /&gt;
* a map which sends every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to an object &amp;lt;math&amp;gt;FA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* a map which sends every morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, to a morphism &amp;lt;math&amp;gt;Ff&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}[FA, FB]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves identities, i.e., &amp;lt;math&amp;gt;F(id_A) = id_{FA}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves composition: &amp;lt;math&amp;gt;F(f \circ g) = F(f) \circ F(g)&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Take a functor &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;f, g, h&amp;lt;/math&amp;gt; three morphisms in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;f&#039; = Ff&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&#039; = Fg&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;h&#039; = Fh&amp;lt;/math&amp;gt;. When &amp;lt;math&amp;gt;h&#039; = f&#039; \circ g&#039;&amp;lt;/math&amp;gt;, can we say something interesting about &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt;?&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
# No, since &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; may not even compose! This is the case when &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; has type &amp;lt;math&amp;gt;A \to B&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;g \colon C \to D&amp;lt;/math&amp;gt;, with &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; collapsing &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; (i.e., &amp;lt;math&amp;gt;FA = FD&amp;lt;/math&amp;gt;).&lt;br /&gt;
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; be the category with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, and exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;. This is a preorder, so &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is monic. Now take &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;, and one extra morphism &amp;lt;math&amp;gt;n \colon \star \to \star&amp;lt;/math&amp;gt;, different from the identity. Because of &amp;lt;math&amp;gt;n \neq id_\star&amp;lt;/math&amp;gt;, yet &amp;lt;math&amp;gt;m \circ n = m \circ id&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is not monic in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;. The functor which sends &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, does not preserve monomorphisms.&lt;br /&gt;
# In general, the answer is (again) no. For monos, take for example the functor &amp;lt;math&amp;gt;\mathcal{C} \to \mathbf{2}&amp;lt;/math&amp;gt; which sends &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; to the identity. Yet, when &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is &#039;&#039;faithful&#039;&#039;, then &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is monic (or epic).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is faithful when, for any two morphisms &amp;lt;math&amp;gt;f, g&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;Ff = Fg&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;f=g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is injective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is full when, for any two objects &amp;lt;math&amp;gt;A, B&amp;lt;/math&amp;gt;, if &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; is a morphism &amp;lt;math&amp;gt;FA \to FB&amp;lt;/math&amp;gt;, then there exists &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;Ff = g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is surjective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; be the functor which sends:&lt;br /&gt;
* every set &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt; to the free group generated by &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* every function &amp;lt;math&amp;gt;f \colon X \to Y&amp;lt;/math&amp;gt; to a group morphism defined by: &amp;lt;math&amp;gt;Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;f\colon X \to Y&amp;lt;/math&amp;gt; be a morphism in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, then &amp;lt;math&amp;gt;Y_A(f)&amp;lt;/math&amp;gt; is expected to be a function from the set &amp;lt;math&amp;gt;\mathcal{C}[Y, A]&amp;lt;/math&amp;gt; to the set &amp;lt;math&amp;gt;\mathcal{C}[X, A]&amp;lt;/math&amp;gt;. We can take, for any morphism &amp;lt;math&amp;gt;m \in \mathcal{C}[Y,A]&amp;lt;/math&amp;gt;: &amp;lt;math&amp;gt;Y_A(f)(m) = m \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This extends &amp;lt;math&amp;gt;Y_A&amp;lt;/math&amp;gt; to a contravariant functor, since &amp;lt;math&amp;gt;Y_A(id_X) = id_{\mathcal{C}[X, A]}&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; be two functors &amp;lt;math&amp;gt;\mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;. A natural transformation &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt; from &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a morphism &amp;lt;math&amp;gt;\alpha_A \colon FA \to GA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt; for every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;,&lt;br /&gt;
* such that, for any morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;Gf \circ \alpha_A = \alpha_B \circ Ff&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Adjunctions and Monads==&lt;br /&gt;
&lt;br /&gt;
===2-categories and their diagrammatic calculus===&lt;br /&gt;
&lt;br /&gt;
This part is just to make the definitions of monads and adjunctions&lt;br /&gt;
easier: we do not give the full details, and only intend to provide a&lt;br /&gt;
few intuitions.&lt;br /&gt;
&lt;br /&gt;
{{Definition | A &#039;&#039;2-category&#039;&#039; is like a category: it has objects and&lt;br /&gt;
morphisms between them. But it also has &#039;&#039;2-cells&#039;&#039;, which are&lt;br /&gt;
&#039;morphisms between morphisms&#039;: &lt;br /&gt;
[[Image:2-cat-1.png|center|A 2-cell]] &lt;br /&gt;
These&lt;br /&gt;
2-cells must compose vertically and horizontally, satisfying the&lt;br /&gt;
&#039;&#039;interchange law&#039;&#039;:&lt;br /&gt;
[[Image:2-cat-inter.png|center|Interchange law]]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
There is a more comfortable representation than the &#039;2-diagrams&#039; above.&lt;br /&gt;
In pictures:&lt;br /&gt;
[[Image:Poincare.png|center|String diagram example]]&lt;br /&gt;
In words, the idea is to consider:&lt;br /&gt;
* objects as background colors, &lt;br /&gt;
* morphisms as vertical frontiers between them, and&lt;br /&gt;
* 2-cells as labelled dots.&lt;br /&gt;
&lt;br /&gt;
Then, both compositions correspond to horizontal and vertical&lt;br /&gt;
juxtaposition, respectively.  For example, the interchange law&lt;br /&gt;
corresponds to the two ways of parsing:&lt;br /&gt;
[[Image:interchange.png|center|Interchange law in a string diagram]]&lt;br /&gt;
&lt;br /&gt;
There are technical subtleties hidden behind this nice diagrammatic&lt;br /&gt;
calculus, but we will stick to bare intuitions for now.&lt;br /&gt;
&lt;br /&gt;
===Cat as a 2-category===&lt;br /&gt;
&lt;br /&gt;
The prime example of a 2-category is of course Cat, the category of (small) categories. It has:&lt;br /&gt;
* objects: small categories,&lt;br /&gt;
* morphisms: functors,&lt;br /&gt;
* 2-cells: natural transformations.&lt;br /&gt;
&lt;br /&gt;
Vertical composition of 2-cells is the obvious notion of composition&lt;br /&gt;
of natural transformations.&lt;br /&gt;
&lt;br /&gt;
Define the horizontal composition:&lt;br /&gt;
[[Image:vert-comp.png|center|Vertical composition]] &lt;br /&gt;
by &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{f&#039; (\alpha_a)} f&#039; (g (a)) &lt;br /&gt;
\xrightarrow{\beta_{g (a)}} g&#039; (g (a)) &amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
or equivalently&lt;br /&gt;
 &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{\beta_{f (a)}} g&#039; (f (a)) &lt;br /&gt;
\xrightarrow{g&#039; (\alpha_a)} g&#039; (g (a)).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
The two coincide by naturality. Observe that what we have actually done is:&lt;br /&gt;
* define &#039;&#039;whiskering&#039;&#039;, i.e., composing with an identity, both to the left and to the right, and &lt;br /&gt;
* observe that the two ways of defining horizontal composition from whiskering coincide.&lt;br /&gt;
This yields an equivalent definition of 2-categories.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Monads==&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;Free&#039;&#039; constructions in algebra: monoid, group, etc&lt;br /&gt;
&lt;br /&gt;
*Definition of a monad&lt;br /&gt;
*Eilenberg-Moore&#039;s category of algebras&lt;br /&gt;
*Kleisli&#039;s category of free algebras&lt;br /&gt;
*The category of resolutions of a monad&lt;br /&gt;
===Adjunctions===&lt;br /&gt;
&lt;br /&gt;
*Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt;&lt;br /&gt;
*Definition with hom-sets&lt;br /&gt;
*Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;&lt;br /&gt;
*Adjunctions in a 2-category&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
*Discussion: any syntax defines the free something&lt;br /&gt;
* The issue of variable binding.&lt;br /&gt;
*Adjunction between partial orders = Galois connection&lt;br /&gt;
*&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic&lt;br /&gt;
*Sets/graphs and categories&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
*Composition&lt;br /&gt;
*Preservation of limits/colimits&lt;br /&gt;
*Freyd&#039;s existence theorem, the locally presentable case&lt;br /&gt;
*Beck&#039;s monadicity theorem&lt;br /&gt;
==Limits and Colimits==&lt;br /&gt;
&lt;br /&gt;
===Limits===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Cartesian product.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Binary product.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The product of X and Y, if it exists, is unique up to isomorphism.&#039;&#039; (with proof)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Set, Grp, Ab, Part.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Preorder, Subset(E), Prop with entailment.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Diagram. Cone. Limit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Limits in Set.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for products, pullbacks, equalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Monos as pullbacks.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The limit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; products and equalizers has &amp;quot;all&amp;quot; limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with a terminal object and all binary products and all equalizers has all finite limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Colimits===&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Cocone. Colimit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Sums in Set, Grp, Ab.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for sums, initial objects, pushouts, coequalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Epis as pushouts.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The colimit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The most general unifier (of two terms) is a coequalizer in the &amp;quot;category of substitutions&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; sums and coequalizers has &amp;quot;all&amp;quot; colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with an initial object and all binary sums and all coequalizers has all finite colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Limits, colimits and adjunctions===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A right adjoint preserves limits. A left adjoint preserves colimits.&#039;&#039; (with proof of existence)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The adjunction between Set and Grp&lt;br /&gt;
&lt;br /&gt;
===Sums and products===&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;distributive&#039;&#039; if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;extensive&#039;&#039; if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; &amp;quot;if..then..else..&amp;quot; from B=1+1 and extensivity.&lt;br /&gt;
 &lt;br /&gt;
==Monoidal categories==&lt;br /&gt;
&lt;br /&gt;
===Definition and graphical calculus===&lt;br /&gt;
&lt;br /&gt;
* Definition&lt;br /&gt;
* Graphical calculus&lt;br /&gt;
* The 2-category of monoidal categories, strong monoidal functors, and monoidal transformations&lt;br /&gt;
* Coherence and its many definitions&lt;br /&gt;
&lt;br /&gt;
===From planar to symmetric monoidal categories===&lt;br /&gt;
&lt;br /&gt;
A teaser for the whole enchilada of variations on monoidal structure.&lt;br /&gt;
&lt;br /&gt;
* Braided &lt;br /&gt;
* Balanced&lt;br /&gt;
* Symmetric&lt;br /&gt;
* Compact closed&lt;br /&gt;
* Traced monoidal categories and the Int/GoI construction&lt;br /&gt;
&lt;br /&gt;
===Monoidal categories for linear logic===&lt;br /&gt;
&lt;br /&gt;
* Linear logic &lt;br /&gt;
** Sequent calculus&lt;br /&gt;
** Intuitionnistic variant&lt;br /&gt;
** Proof nets&lt;br /&gt;
&lt;br /&gt;
* Symmetric monoidal closed categories&lt;br /&gt;
&lt;br /&gt;
* Star-autonomous categories&lt;br /&gt;
** Symmetric monoidal closed category with a dualising object&lt;br /&gt;
** Symmetric monoidal category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with:&lt;br /&gt;
*** a full and faithful contravariant endofunctor &amp;lt;math&amp;gt;\mathcal{C}^{op} \xrightarrow{(-)^*} \mathcal{C} &amp;lt;/math&amp;gt;, and&lt;br /&gt;
*** an isomorphism &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\mathcal{C} (A \otimes B, C^*) \cong \mathcal{C} (A, (B \otimes C)^*).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Trimble-Hughes&#039; free star-autonomous category&lt;br /&gt;
** Split star-autonomy&lt;br /&gt;
** The free star-autonomous category as a category of proof nets&lt;br /&gt;
** Trimble rewiring&lt;br /&gt;
&lt;br /&gt;
===Perspectives===&lt;br /&gt;
&lt;br /&gt;
* Premonoidal categories and side effects&lt;br /&gt;
* Products and coproducts&lt;br /&gt;
* Monoidal 2-categories, monoidal double categories.&lt;br /&gt;
&lt;br /&gt;
==Presheaves and sheaves==&lt;br /&gt;
&lt;br /&gt;
===Yoneda===&lt;br /&gt;
&lt;br /&gt;
*A few presheaf categories &amp;lt;math&amp;gt;\hat{\mathcal{C}} := \mathcal{C}^{op} \to \mathbf{Set}&amp;lt;/math&amp;gt;:&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a graph (no composition): graphs.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a preorder: Kripke-style modal logic.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is an order: presheaves on a topological space.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is free: presheaves on an algebraic theory.&lt;br /&gt;
&lt;br /&gt;
*Representable presheaves &amp;lt;math&amp;gt;yA(B) := \mathcal{C}(B, A)&amp;lt;/math&amp;gt;, and their meaning in each of the examples.&lt;br /&gt;
&lt;br /&gt;
*The Yoneda lemma: for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and presheaf &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt;, there is an isomorphism&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;F (A) \cong \hat{\mathcal{C}} (yA, F),&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
natural in &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
*A consequence: &amp;lt;math&amp;gt;y&amp;lt;/math&amp;gt; is a &#039;full embedding&#039;, or how &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a full subcategory of &amp;lt;math&amp;gt;\hat{\mathcal{C}}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
*Presheaves as a colimit completion&lt;br /&gt;
**The Grothendieck construction, or the category of elements of a presehaf.&lt;br /&gt;
**Example: graphs.&lt;br /&gt;
**Every presheaf is a colimit of representables.&lt;br /&gt;
**Example: graphs.&lt;br /&gt;
**The universal property of &amp;lt;math&amp;gt;y&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Topos structure===&lt;br /&gt;
&lt;br /&gt;
*Limits and colimits in functor categories.&lt;br /&gt;
*Exponentials. If it exists, the exponential &amp;lt;math&amp;gt;G^F&amp;lt;/math&amp;gt; must satisfy, for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;:&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\begin{array}{lcl}&lt;br /&gt;
G^F(A) &amp;amp; \cong &amp;amp; \hat{\mathcal{C}} (yA, G^F) \\&lt;br /&gt;
&amp;amp; \cong &amp;amp; \hat{\mathcal{C}} (yA \times F, G).&lt;br /&gt;
\end{array}&lt;br /&gt;
&amp;lt;/math&amp;gt;&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
Taking this as a definition indeed yields an exponential.&lt;br /&gt;
*Computation of the exponential in &#039;&#039;&#039;Gph&#039;&#039;&#039;.&lt;br /&gt;
*The very special presheaf &amp;lt;math&amp;gt;\Omega&amp;lt;/math&amp;gt;.&lt;br /&gt;
*The isomorphism &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\mathit{Sub}(F) \cong \hat{\mathcal{C}} (F, \Omega). &amp;lt;/math&amp;gt;&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
*The official definition of a subobject classifier.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4096</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4096"/>
		<updated>2009-03-27T14:38:57Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
* March 4. : monads, adjunctions.&lt;br /&gt;
* March 11. : limits and colimits.&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; from a category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to a category &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, noted &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, is given by:&lt;br /&gt;
* a map which sends every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to an object &amp;lt;math&amp;gt;FA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* a map which sends every morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, to a morphism &amp;lt;math&amp;gt;Ff&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}[FA, FB]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves identities, i.e., &amp;lt;math&amp;gt;F(id_A) = id_{FA}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves composition: &amp;lt;math&amp;gt;F(f \circ g) = F(f) \circ F(g)&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Take a functor &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;f, g, h&amp;lt;/math&amp;gt; three morphisms in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;f&#039; = Ff&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&#039; = Fg&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;h&#039; = Fh&amp;lt;/math&amp;gt;. When &amp;lt;math&amp;gt;h&#039; = f&#039; \circ g&#039;&amp;lt;/math&amp;gt;, can we say something interesting about &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt;?&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
# No, since &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; may not even compose! This is the case when &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; has type &amp;lt;math&amp;gt;A \to B&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;g \colon C \to D&amp;lt;/math&amp;gt;, with &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; collapsing &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; (i.e., &amp;lt;math&amp;gt;FA = FD&amp;lt;/math&amp;gt;).&lt;br /&gt;
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; be the category with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, and exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;. This is a preorder, so &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is monic. Now take &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;, and one extra morphism &amp;lt;math&amp;gt;n \colon \star \to \star&amp;lt;/math&amp;gt;, different from the identity. Because of &amp;lt;math&amp;gt;n \neq id_\star&amp;lt;/math&amp;gt;, yet &amp;lt;math&amp;gt;m \circ n = m \circ id&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is not monic in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;. The functor which sends &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, does not preserve monomorphisms.&lt;br /&gt;
# In general, the answer is (again) no. For monos, take for example the functor &amp;lt;math&amp;gt;\mathcal{C} \to \mathbf{2}&amp;lt;/math&amp;gt; which sends &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; to the identity. Yet, when &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is &#039;&#039;faithful&#039;&#039;, then &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is monic (or epic).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is faithful when, for any two morphisms &amp;lt;math&amp;gt;f, g&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;Ff = Fg&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;f=g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is injective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is full when, for any two objects &amp;lt;math&amp;gt;A, B&amp;lt;/math&amp;gt;, if &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; is a morphism &amp;lt;math&amp;gt;FA \to FB&amp;lt;/math&amp;gt;, then there exists &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;Ff = g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is surjective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; be the functor which sends:&lt;br /&gt;
* every set &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt; to the free group generated by &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* every function &amp;lt;math&amp;gt;f \colon X \to Y&amp;lt;/math&amp;gt; to a group morphism defined by: &amp;lt;math&amp;gt;Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;f\colon X \to Y&amp;lt;/math&amp;gt; be a morphism in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, then &amp;lt;math&amp;gt;Y_A(f)&amp;lt;/math&amp;gt; is expected to be a function from the set &amp;lt;math&amp;gt;\mathcal{C}[Y, A]&amp;lt;/math&amp;gt; to the set &amp;lt;math&amp;gt;\mathcal{C}[X, A]&amp;lt;/math&amp;gt;. We can take, for any morphism &amp;lt;math&amp;gt;m \in \mathcal{C}[Y,A]&amp;lt;/math&amp;gt;: &amp;lt;math&amp;gt;Y_A(f)(m) = m \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This extends &amp;lt;math&amp;gt;Y_A&amp;lt;/math&amp;gt; to a contravariant functor, since &amp;lt;math&amp;gt;Y_A(id_X) = id_{\mathcal{C}[X, A]}&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; be two functors &amp;lt;math&amp;gt;\mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;. A natural transformation &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt; from &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a morphism &amp;lt;math&amp;gt;\alpha_A \colon FA \to GA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt; for every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;,&lt;br /&gt;
* such that, for any morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;Gf \circ \alpha_A = \alpha_B \circ Ff&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Adjunctions and Monads==&lt;br /&gt;
&lt;br /&gt;
===2-categories and their diagrammatic calculus===&lt;br /&gt;
&lt;br /&gt;
This part is just to make the definitions of monads and adjunctions&lt;br /&gt;
easier: we do not give the full details, and only intend to provide a&lt;br /&gt;
few intuitions.&lt;br /&gt;
&lt;br /&gt;
{{Definition | A &#039;&#039;2-category&#039;&#039; is like a category: it has objects and&lt;br /&gt;
morphisms between them. But it also has &#039;&#039;2-cells&#039;&#039;, which are&lt;br /&gt;
&#039;morphisms between morphisms&#039;: &lt;br /&gt;
[[Image:2-cat-1.png|center|A 2-cell]] &lt;br /&gt;
These&lt;br /&gt;
2-cells must compose vertically and horizontally, satisfying the&lt;br /&gt;
&#039;&#039;interchange law&#039;&#039;:&lt;br /&gt;
[[Image:2-cat-inter.png|center|Interchange law]]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
There is a more comfortable representation than the &#039;2-diagrams&#039; above.&lt;br /&gt;
In pictures:&lt;br /&gt;
[[Image:Poincare.png|center|String diagram example]]&lt;br /&gt;
In words, the idea is to consider:&lt;br /&gt;
* objects as background colors, &lt;br /&gt;
* morphisms as vertical frontiers between them, and&lt;br /&gt;
* 2-cells as labelled dots.&lt;br /&gt;
&lt;br /&gt;
Then, both compositions correspond to horizontal and vertical&lt;br /&gt;
juxtaposition, respectively.  For example, the interchange law&lt;br /&gt;
corresponds to the two ways of parsing:&lt;br /&gt;
[[Image:interchange.png|center|Interchange law in a string diagram]]&lt;br /&gt;
&lt;br /&gt;
There are technical subtleties hidden behind this nice diagrammatic&lt;br /&gt;
calculus, but we will stick to bare intuitions for now.&lt;br /&gt;
&lt;br /&gt;
===Cat as a 2-category===&lt;br /&gt;
&lt;br /&gt;
The prime example of a 2-category is of course Cat, the category of (small) categories. It has:&lt;br /&gt;
* objects: small categories,&lt;br /&gt;
* morphisms: functors,&lt;br /&gt;
* 2-cells: natural transformations.&lt;br /&gt;
&lt;br /&gt;
Vertical composition of 2-cells is the obvious notion of composition&lt;br /&gt;
of natural transformations.&lt;br /&gt;
&lt;br /&gt;
Define the horizontal composition:&lt;br /&gt;
[[Image:vert-comp.png|center|Vertical composition]] &lt;br /&gt;
by &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{f&#039; (\alpha_a)} f&#039; (g (a)) &lt;br /&gt;
\xrightarrow{\beta_{g (a)}} g&#039; (g (a)) &amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
or equivalently&lt;br /&gt;
 &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{\beta_{f (a)}} g&#039; (f (a)) &lt;br /&gt;
\xrightarrow{g&#039; (\alpha_a)} g&#039; (g (a)).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
The two coincide by naturality. Observe that what we have actually done is:&lt;br /&gt;
* define &#039;&#039;whiskering&#039;&#039;, i.e., composing with an identity, both to the left and to the right, and &lt;br /&gt;
* observe that the two ways of defining horizontal composition from whiskering coincide.&lt;br /&gt;
This yields an equivalent definition of 2-categories.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Monads==&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;Free&#039;&#039; constructions in algebra: monoid, group, etc&lt;br /&gt;
&lt;br /&gt;
*Definition of a monad&lt;br /&gt;
*Eilenberg-Moore&#039;s category of algebras&lt;br /&gt;
*Kleisli&#039;s category of free algebras&lt;br /&gt;
*The category of resolutions of a monad&lt;br /&gt;
===Adjunctions===&lt;br /&gt;
&lt;br /&gt;
*Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt;&lt;br /&gt;
*Definition with hom-sets&lt;br /&gt;
*Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;&lt;br /&gt;
*Adjunctions in a 2-category&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
*Discussion: any syntax defines the free something&lt;br /&gt;
* The issue of variable binding.&lt;br /&gt;
*Adjunction between partial orders = Galois connection&lt;br /&gt;
*&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic&lt;br /&gt;
*Sets/graphs and categories&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
*Composition&lt;br /&gt;
*Preservation of limits/colimits&lt;br /&gt;
*Freyd&#039;s existence theorem, the locally presentable case&lt;br /&gt;
*Beck&#039;s monadicity theorem&lt;br /&gt;
==Limits and Colimits==&lt;br /&gt;
&lt;br /&gt;
===Limits===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Cartesian product.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Binary product.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The product of X and Y, if it exists, is unique up to isomorphism.&#039;&#039; (with proof)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Set, Grp, Ab, Part.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Preorder, Subset(E), Prop with entailment.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Diagram. Cone. Limit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Limits in Set.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for products, pullbacks, equalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Monos as pullbacks.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The limit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; products and equalizers has &amp;quot;all&amp;quot; limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with a terminal object and all binary products and all equalizers has all finite limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Colimits===&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Cocone. Colimit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Sums in Set, Grp, Ab.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for sums, initial objects, pushouts, coequalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Epis as pushouts.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The colimit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The most general unifier (of two terms) is a coequalizer in the &amp;quot;category of substitutions&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; sums and coequalizers has &amp;quot;all&amp;quot; colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with an initial object and all binary sums and all coequalizers has all finite colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Limits, colimits and adjunctions===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A right adjoint preserves limits. A left adjoint preserves colimits.&#039;&#039; (with proof of existence)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The adjunction between Set and Grp&lt;br /&gt;
&lt;br /&gt;
===Sums and products===&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;distributive&#039;&#039; if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;extensive&#039;&#039; if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; &amp;quot;if..then..else..&amp;quot; from B=1+1 and extensivity.&lt;br /&gt;
 &lt;br /&gt;
==Monoidal categories==&lt;br /&gt;
&lt;br /&gt;
===Definition and graphical calculus===&lt;br /&gt;
&lt;br /&gt;
* Definition&lt;br /&gt;
* Graphical calculus&lt;br /&gt;
* The 2-category of monoidal categories, strong monoidal functors, and monoidal transformations&lt;br /&gt;
* Coherence and its many definitions&lt;br /&gt;
&lt;br /&gt;
===From planar to symmetric monoidal categories===&lt;br /&gt;
&lt;br /&gt;
A teaser for the whole enchilada of variations on monoidal structure.&lt;br /&gt;
&lt;br /&gt;
* Braided &lt;br /&gt;
* Balanced&lt;br /&gt;
* Symmetric&lt;br /&gt;
* Compact closed&lt;br /&gt;
* Traced monoidal categories and the Int/GoI construction&lt;br /&gt;
&lt;br /&gt;
===Monoidal categories for linear logic===&lt;br /&gt;
&lt;br /&gt;
* Linear logic &lt;br /&gt;
** Sequent calculus&lt;br /&gt;
** Intuitionnistic variant&lt;br /&gt;
** Proof nets&lt;br /&gt;
&lt;br /&gt;
* Symmetric monoidal closed categories&lt;br /&gt;
&lt;br /&gt;
* Star-autonomous categories&lt;br /&gt;
** Symmetric monoidal closed category with a dualising object&lt;br /&gt;
** Symmetric monoidal category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with:&lt;br /&gt;
*** a full and faithful contravariant endofunctor &amp;lt;math&amp;gt;\mathcal{C}^{op} \xrightarrow{(-)^*} \mathcal{C} &amp;lt;/math&amp;gt;, and&lt;br /&gt;
*** an isomorphism &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\mathcal{C} (A \otimes B, C^*) \cong \mathcal{C} (A, (B \otimes C)^*).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Trimble-Hughes&#039; free star-autonomous category&lt;br /&gt;
** Split star-autonomy&lt;br /&gt;
** The free star-autonomous category as a category of proof nets&lt;br /&gt;
** Trimble rewiring&lt;br /&gt;
&lt;br /&gt;
===Perspectives===&lt;br /&gt;
&lt;br /&gt;
* Premonoidal categories and side effects&lt;br /&gt;
* Products and coproducts&lt;br /&gt;
* Monoidal 2-categories, monoidal double categories.&lt;br /&gt;
&lt;br /&gt;
==Presheaves and sheaves==&lt;br /&gt;
&lt;br /&gt;
===Yoneda===&lt;br /&gt;
&lt;br /&gt;
*A few presheaf categories &amp;lt;math&amp;gt;\hat{\mathcal{C}} := \mathcal{C}^{op} \to &#039;&#039;&#039;Set&#039;&#039;&#039;&amp;lt;/math&amp;gt;:&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a graph (no composition): graphs.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a preorder: Kripke-style modal logic.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is an order: presheaves on a topological space.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is free: presheaves on an algebraic theory.&lt;br /&gt;
&lt;br /&gt;
*Representable presheaves &amp;lt;math&amp;gt;yA(B) := \mathcal{C}(B, A)&amp;lt;/math&amp;gt;, and their meaning in each of the examples.&lt;br /&gt;
&lt;br /&gt;
*The Yoneda lemma: for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and presheaf &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt;, there is an isomorphism&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;F (A) \cong \hat{\mathcal{C}} (yA, F),&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
natural in &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
*A consequence: &amp;lt;math&amp;gt;y&amp;lt;/math&amp;gt; is a &#039;full embedding&#039;, or how &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a full subcategory of &amp;lt;math&amp;gt;\hat{\mathcal{C}}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
*Presheaves as a colimit completion&lt;br /&gt;
**The Grothendieck construction, or the category of elements of a presehaf.&lt;br /&gt;
**Example: graphs.&lt;br /&gt;
**Every presheaf is a colimit of representables.&lt;br /&gt;
**Example: graphs.&lt;br /&gt;
**The universal property of &amp;lt;math&amp;gt;y&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Topos structure===&lt;br /&gt;
&lt;br /&gt;
*Limits and colimits in functor categories.&lt;br /&gt;
*Exponentials. If it exists, the exponential &amp;lt;math&amp;gt;G^F&amp;lt;/math&amp;gt; must satisfy, for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;:&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\begin{array}{lcl}&lt;br /&gt;
G^F(A) &amp;amp; \cong &amp;amp; \hat{\mathcal{C}} (yA, G^F) \\&lt;br /&gt;
&amp;amp; \cong &amp;amp; \hat{\mathcal{C}} (yA \times F, G).&lt;br /&gt;
\end{array}&lt;br /&gt;
&amp;lt;/math&amp;gt;&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
Taking this as a definition indeed yields an exponential.&lt;br /&gt;
*Computation of the exponential in &#039;&#039;&#039;Gph&#039;&#039;&#039;.&lt;br /&gt;
*The very special presheaf &amp;lt;math&amp;gt;\Omega&amp;lt;/math&amp;gt;.&lt;br /&gt;
*The isomorphism &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\mathit{Sub}(F) \cong \hat{\mathcal{C}} (F, \Omega). &amp;lt;/math&amp;gt;&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
*The official definition of a subobject classifier.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4095</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4095"/>
		<updated>2009-03-27T14:33:43Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
* March 4. : monads, adjunctions.&lt;br /&gt;
* March 11. : limits and colimits.&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; from a category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to a category &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, noted &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, is given by:&lt;br /&gt;
* a map which sends every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to an object &amp;lt;math&amp;gt;FA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* a map which sends every morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, to a morphism &amp;lt;math&amp;gt;Ff&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}[FA, FB]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves identities, i.e., &amp;lt;math&amp;gt;F(id_A) = id_{FA}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves composition: &amp;lt;math&amp;gt;F(f \circ g) = F(f) \circ F(g)&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Take a functor &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;f, g, h&amp;lt;/math&amp;gt; three morphisms in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;f&#039; = Ff&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&#039; = Fg&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;h&#039; = Fh&amp;lt;/math&amp;gt;. When &amp;lt;math&amp;gt;h&#039; = f&#039; \circ g&#039;&amp;lt;/math&amp;gt;, can we say something interesting about &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt;?&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
# No, since &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; may not even compose! This is the case when &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; has type &amp;lt;math&amp;gt;A \to B&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;g \colon C \to D&amp;lt;/math&amp;gt;, with &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; collapsing &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; (i.e., &amp;lt;math&amp;gt;FA = FD&amp;lt;/math&amp;gt;).&lt;br /&gt;
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; be the category with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, and exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;. This is a preorder, so &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is monic. Now take &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;, and one extra morphism &amp;lt;math&amp;gt;n \colon \star \to \star&amp;lt;/math&amp;gt;, different from the identity. Because of &amp;lt;math&amp;gt;n \neq id_\star&amp;lt;/math&amp;gt;, yet &amp;lt;math&amp;gt;m \circ n = m \circ id&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is not monic in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;. The functor which sends &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, does not preserve monomorphisms.&lt;br /&gt;
# In general, the answer is (again) no. For monos, take for example the functor &amp;lt;math&amp;gt;\mathcal{C} \to \mathbf{2}&amp;lt;/math&amp;gt; which sends &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; to the identity. Yet, when &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is &#039;&#039;faithful&#039;&#039;, then &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is monic (or epic).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is faithful when, for any two morphisms &amp;lt;math&amp;gt;f, g&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;Ff = Fg&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;f=g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is injective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is full when, for any two objects &amp;lt;math&amp;gt;A, B&amp;lt;/math&amp;gt;, if &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; is a morphism &amp;lt;math&amp;gt;FA \to FB&amp;lt;/math&amp;gt;, then there exists &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;Ff = g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is surjective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; be the functor which sends:&lt;br /&gt;
* every set &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt; to the free group generated by &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* every function &amp;lt;math&amp;gt;f \colon X \to Y&amp;lt;/math&amp;gt; to a group morphism defined by: &amp;lt;math&amp;gt;Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;f\colon X \to Y&amp;lt;/math&amp;gt; be a morphism in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, then &amp;lt;math&amp;gt;Y_A(f)&amp;lt;/math&amp;gt; is expected to be a function from the set &amp;lt;math&amp;gt;\mathcal{C}[Y, A]&amp;lt;/math&amp;gt; to the set &amp;lt;math&amp;gt;\mathcal{C}[X, A]&amp;lt;/math&amp;gt;. We can take, for any morphism &amp;lt;math&amp;gt;m \in \mathcal{C}[Y,A]&amp;lt;/math&amp;gt;: &amp;lt;math&amp;gt;Y_A(f)(m) = m \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This extends &amp;lt;math&amp;gt;Y_A&amp;lt;/math&amp;gt; to a contravariant functor, since &amp;lt;math&amp;gt;Y_A(id_X) = id_{\mathcal{C}[X, A]}&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; be two functors &amp;lt;math&amp;gt;\mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;. A natural transformation &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt; from &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a morphism &amp;lt;math&amp;gt;\alpha_A \colon FA \to GA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt; for every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;,&lt;br /&gt;
* such that, for any morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;Gf \circ \alpha_A = \alpha_B \circ Ff&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
==Adjunctions and Monads==&lt;br /&gt;
&lt;br /&gt;
===Preliminaries===&lt;br /&gt;
&lt;br /&gt;
====2-categories and their diagrammatic calculus====&lt;br /&gt;
This part is just to make the definitions of monads and adjunctions&lt;br /&gt;
easier: we do not give the full details, and only intend to provide a&lt;br /&gt;
few intuitions.&lt;br /&gt;
&lt;br /&gt;
{{Definition | A &#039;&#039;2-category&#039;&#039; is like a category: it has objects and&lt;br /&gt;
morphisms between them. But it also has &#039;&#039;2-cells&#039;&#039;, which are&lt;br /&gt;
&#039;morphisms between morphisms&#039;: &lt;br /&gt;
[[Image:2-cat-1.png|center|A 2-cell]] &lt;br /&gt;
These&lt;br /&gt;
2-cells must compose vertically and horizontally, satisfying the&lt;br /&gt;
&#039;&#039;interchange law&#039;&#039;:&lt;br /&gt;
[[Image:2-cat-inter.png|center|Interchange law]]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
There is a more comfortable representation than the &#039;2-diagrams&#039; above.&lt;br /&gt;
In pictures:&lt;br /&gt;
[[Image:Poincare.png|center|String diagram example]]&lt;br /&gt;
In words, the idea is to consider:&lt;br /&gt;
* objects as background colors, &lt;br /&gt;
* morphisms as vertical frontiers between them, and&lt;br /&gt;
* 2-cells as labelled dots.&lt;br /&gt;
&lt;br /&gt;
Then, both compositions correspond to horizontal and vertical&lt;br /&gt;
juxtaposition, respectively.  For example, the interchange law&lt;br /&gt;
corresponds to the two ways of parsing:&lt;br /&gt;
[[Image:interchange.png|center|Interchange law in a string diagram]]&lt;br /&gt;
&lt;br /&gt;
====CAT as a 2-category====&lt;br /&gt;
&lt;br /&gt;
The prime example of a 2-category is of course Cat, the category of (small) categories. It has:&lt;br /&gt;
* objects: small categories,&lt;br /&gt;
* morphisms: functors,&lt;br /&gt;
* 2-cells: natural transformations.&lt;br /&gt;
&lt;br /&gt;
Vertical composition of 2-cells is the obvious notion of composition&lt;br /&gt;
of natural transformations.&lt;br /&gt;
&lt;br /&gt;
Define the horizontal composition:&lt;br /&gt;
[[Image:vert-comp.png|center|Vertical composition]] &lt;br /&gt;
by &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{f&#039; (\alpha_a)} f&#039; (g (a)) &lt;br /&gt;
\xrightarrow{\beta_{g (a)}} g&#039; (g (a)) &amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
or equivalently&lt;br /&gt;
 &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{\beta_{f (a)}} g&#039; (f (a)) &lt;br /&gt;
\xrightarrow{g&#039; (\alpha_a)} g&#039; (g (a)).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
The two coincide by naturality. Observe that what we have actually done is:&lt;br /&gt;
* define &#039;&#039;whiskering&#039;&#039;, i.e., composing with an identity, both to the left and to the right, and &lt;br /&gt;
* observe that the two ways of defining horizontal composition from whiskering coincide.&lt;br /&gt;
This yields an equivalent definition of 2-categories.&lt;br /&gt;
&lt;br /&gt;
===Monads===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;Free&#039;&#039; constructions in algebra: monoid, group, etc====&lt;br /&gt;
&lt;br /&gt;
====Definition of a monad====&lt;br /&gt;
&lt;br /&gt;
====Eilenberg-Moore&#039;s category of algebras====&lt;br /&gt;
&lt;br /&gt;
====Kleisli&#039;s category of free algebras====&lt;br /&gt;
&lt;br /&gt;
====The category of resolutions of a monad====&lt;br /&gt;
&lt;br /&gt;
===Adjunctions===&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Definition with hom-sets====&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Adjunctions in a 2-category====&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
====Discussion: any syntax defines the free something==== &lt;br /&gt;
The issue of &lt;br /&gt;
variable binding.&lt;br /&gt;
====Adjunction between partial orders = Galois connection====&lt;br /&gt;
====&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic====&lt;br /&gt;
====Sets/graphs and categories====&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
====Composition====&lt;br /&gt;
====Preservation of limits/colimits====&lt;br /&gt;
====Freyd&#039;s existence theorem, the locally presentable case====&lt;br /&gt;
====Beck&#039;s monadicity theorem====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Limits and Colimits==&lt;br /&gt;
&lt;br /&gt;
===Limits===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Cartesian product.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Binary product.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The product of X and Y, if it exists, is unique up to isomorphism.&#039;&#039; (with proof)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Set, Grp, Ab, Part.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Preorder, Subset(E), Prop with entailment.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Diagram. Cone. Limit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Limits in Set.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for products, pullbacks, equalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Monos as pullbacks.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The limit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; products and equalizers has &amp;quot;all&amp;quot; limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with a terminal object and all binary products and all equalizers has all finite limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Colimits===&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Cocone. Colimit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Sums in Set, Grp, Ab.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for sums, initial objects, pushouts, coequalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Epis as pushouts.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The colimit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The most general unifier (of two terms) is a coequalizer in the &amp;quot;category of substitutions&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; sums and coequalizers has &amp;quot;all&amp;quot; colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with an initial object and all binary sums and all coequalizers has all finite colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Limits, colimits and adjunctions===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A right adjoint preserves limits. A left adjoint preserves colimits.&#039;&#039; (with proof of existence)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The adjunction between Set and Grp&lt;br /&gt;
&lt;br /&gt;
===Sums and products===&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;distributive&#039;&#039; if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;extensive&#039;&#039; if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; &amp;quot;if..then..else..&amp;quot; from B=1+1 and extensivity.&lt;br /&gt;
 &lt;br /&gt;
==Monoidal categories==&lt;br /&gt;
&lt;br /&gt;
===Definition and graphical calculus===&lt;br /&gt;
&lt;br /&gt;
* Definition&lt;br /&gt;
* Graphical calculus&lt;br /&gt;
* The 2-category of monoidal categories, strong monoidal functors, and monoidal transformations&lt;br /&gt;
* Coherence and its many definitions&lt;br /&gt;
&lt;br /&gt;
===From planar to symmetric monoidal categories===&lt;br /&gt;
&lt;br /&gt;
A teaser for the whole enchilada of variations on monoidal structure.&lt;br /&gt;
&lt;br /&gt;
* Braided &lt;br /&gt;
* Balanced&lt;br /&gt;
* Symmetric&lt;br /&gt;
* Compact closed&lt;br /&gt;
* Traced monoidal categories and the Int/GoI construction&lt;br /&gt;
&lt;br /&gt;
===Monoidal categories for linear logic===&lt;br /&gt;
&lt;br /&gt;
* Linear logic &lt;br /&gt;
** Sequent calculus&lt;br /&gt;
** Intuitionnistic variant&lt;br /&gt;
** Proof nets&lt;br /&gt;
&lt;br /&gt;
* Symmetric monoidal closed categories&lt;br /&gt;
&lt;br /&gt;
* Star-autonomous categories&lt;br /&gt;
** Symmetric monoidal closed category with a dualising object&lt;br /&gt;
** Symmetric monoidal category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with:&lt;br /&gt;
*** a full and faithful contravariant endofunctor &amp;lt;math&amp;gt;\mathcal{C}^{op} \xrightarrow{(-)^*} \mathcal{C} &amp;lt;/math&amp;gt;, and&lt;br /&gt;
*** an isomorphism &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\mathcal{C} (A \otimes B, C^*) \cong \mathcal{C} (A, (B \otimes C)^*).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Trimble-Hughes&#039; free star-autonomous category&lt;br /&gt;
** Split star-autonomy&lt;br /&gt;
** The free star-autonomous category as a category of proof nets&lt;br /&gt;
** Trimble rewiring&lt;br /&gt;
&lt;br /&gt;
===Perspectives===&lt;br /&gt;
&lt;br /&gt;
* Premonoidal categories and side effects&lt;br /&gt;
* Products and coproducts&lt;br /&gt;
* Monoidal 2-categories, monoidal double categories.&lt;br /&gt;
&lt;br /&gt;
==Presheaves and sheaves==&lt;br /&gt;
&lt;br /&gt;
===Yoneda===&lt;br /&gt;
&lt;br /&gt;
*A few presheaf categories &amp;lt;math&amp;gt;\hat{\mathcal{C}} := \mathcal{C}^{op} \to &#039;&#039;&#039;Set&#039;&#039;&#039;&amp;lt;/math&amp;gt;:&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a graph (no composition): graphs.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a preorder: Kripke-style modal logic.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is an order: presheaves on a topological space.&lt;br /&gt;
**&amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is free: presheaves on an algebraic theory.&lt;br /&gt;
&lt;br /&gt;
*Representable presheaves &amp;lt;math&amp;gt;yA(B) := \mathcal{C}(B, A)&amp;lt;/math&amp;gt;, and their meaning in each of the examples.&lt;br /&gt;
&lt;br /&gt;
*The Yoneda lemma: for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and presheaf &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt;, there is an isomorphism&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;F (A) \cong \hat{\mathcal{C}} (yA, F),&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
natural in &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
*A consequence: &amp;lt;math&amp;gt;y&amp;lt;/math&amp;gt; is a &#039;full embedding&#039;, or how &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a full subcategory of &amp;lt;math&amp;gt;\hat{\mathcal{C}}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
*Presheaves as a colimit completion&lt;br /&gt;
**The Grothendieck construction, or the category of elements of a presehaf.&lt;br /&gt;
**Example: graphs.&lt;br /&gt;
**Every presheaf is a colimit of representables.&lt;br /&gt;
**Example: graphs.&lt;br /&gt;
**The universal property of &amp;lt;math&amp;gt;y&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Topos structure===&lt;br /&gt;
&lt;br /&gt;
*Limits and colimits in functor categories.&lt;br /&gt;
*Exponentials. If it exists, the exponential &amp;lt;math&amp;gt;G^F&amp;lt;/math&amp;gt; must satisfy, for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;:&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\begin{array}{lcl}&lt;br /&gt;
G^F(A) &amp;amp; \cong &amp;amp; \hat{\mathcal{C}} (yA, G^F) \\&lt;br /&gt;
&amp;amp; \cong &amp;amp; \hat{\mathcal{C}} (yA \times F, G).&lt;br /&gt;
\end{array}&lt;br /&gt;
&amp;lt;/math&amp;gt;&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
Taking this as a definition indeed yields an exponential.&lt;br /&gt;
*Computation of the exponential in &#039;&#039;&#039;Gph&#039;&#039;&#039;.&lt;br /&gt;
*The very special presheaf &amp;lt;math&amp;gt;\Omega&amp;lt;/math&amp;gt;.&lt;br /&gt;
*The isomorphism &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\mathit{Sub}(F) \cong \hat{\mathcal{C}} (F, \Omega). &amp;lt;/math&amp;gt;&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
*The official definition of a subobject classifier.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4085</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4085"/>
		<updated>2009-03-27T12:49:18Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
* March 4. : monads, adjunctions.&lt;br /&gt;
* March 11. : limits and colimits.&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; from a category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to a category &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, noted &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, is given by:&lt;br /&gt;
* a map which sends every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to an object &amp;lt;math&amp;gt;FA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* a map which sends every morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, to a morphism &amp;lt;math&amp;gt;Ff&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}[FA, FB]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves identities, i.e., &amp;lt;math&amp;gt;F(id_A) = id_{FA}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves composition: &amp;lt;math&amp;gt;F(f \circ g) = F(f) \circ F(g)&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Take a functor &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;f, g, h&amp;lt;/math&amp;gt; three morphisms in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;f&#039; = Ff&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&#039; = Fg&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;h&#039; = Fh&amp;lt;/math&amp;gt;. When &amp;lt;math&amp;gt;h&#039; = f&#039; \circ g&#039;&amp;lt;/math&amp;gt;, can we say something interesting about &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt;?&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
# No, since &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; may not even compose! This is the case when &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; has type &amp;lt;math&amp;gt;A \to B&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;g \colon C \to D&amp;lt;/math&amp;gt;, with &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; collapsing &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; (i.e., &amp;lt;math&amp;gt;FA = FD&amp;lt;/math&amp;gt;).&lt;br /&gt;
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; be the category with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, and exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;. This is a preorder, so &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is monic. Now take &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;, and one extra morphism &amp;lt;math&amp;gt;n \colon \star \to \star&amp;lt;/math&amp;gt;, different from the identity. Because of &amp;lt;math&amp;gt;n \neq id_\star&amp;lt;/math&amp;gt;, yet &amp;lt;math&amp;gt;m \circ n = m \circ id&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is not monic in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;. The functor which sends &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, does not preserve monomorphisms.&lt;br /&gt;
# In general, the answer is (again) no. For monos, take for example the functor &amp;lt;math&amp;gt;\mathcal{C} \to \mathbf{2}&amp;lt;/math&amp;gt; which sends &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; to the identity. Yet, when &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is &#039;&#039;faithful&#039;&#039;, then &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is monic (or epic).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is faithful when, for any two morphisms &amp;lt;math&amp;gt;f, g&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;Ff = Fg&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;f=g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is injective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is full when, for any two objects &amp;lt;math&amp;gt;A, B&amp;lt;/math&amp;gt;, if &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; is a morphism &amp;lt;math&amp;gt;FA \to FB&amp;lt;/math&amp;gt;, then there exists &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;Ff = g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is surjective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; be the functor which sends:&lt;br /&gt;
* every set &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt; to the free group generated by &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* every function &amp;lt;math&amp;gt;f \colon X \to Y&amp;lt;/math&amp;gt; to a group morphism defined by: &amp;lt;math&amp;gt;Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;f\colon X \to Y&amp;lt;/math&amp;gt; be a morphism in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, then &amp;lt;math&amp;gt;Y_A(f)&amp;lt;/math&amp;gt; is expected to be a function from the set &amp;lt;math&amp;gt;\mathcal{C}[Y, A]&amp;lt;/math&amp;gt; to the set &amp;lt;math&amp;gt;\mathcal{C}[X, A]&amp;lt;/math&amp;gt;. We can take, for any morphism &amp;lt;math&amp;gt;m \in \mathcal{C}[Y,A]&amp;lt;/math&amp;gt;: &amp;lt;math&amp;gt;Y_A(f)(m) = m \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This extends &amp;lt;math&amp;gt;Y_A&amp;lt;/math&amp;gt; to a contravariant functor, since &amp;lt;math&amp;gt;Y_A(id_X) = id_{\mathcal{C}[X, A]}&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; be two functors &amp;lt;math&amp;gt;\mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;. A natural transformation &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt; from &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a morphism &amp;lt;math&amp;gt;\alpha_A \colon FA \to GA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt; for every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;,&lt;br /&gt;
* such that, for any morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;Gf \circ \alpha_A = \alpha_B \circ Ff&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
==Adjunctions and Monads==&lt;br /&gt;
&lt;br /&gt;
===Preliminaries===&lt;br /&gt;
&lt;br /&gt;
====2-categories and their diagrammatic calculus====&lt;br /&gt;
This part is just to make the definitions of monads and adjunctions&lt;br /&gt;
easier: we do not give the full details, and only intend to provide a&lt;br /&gt;
few intuitions.&lt;br /&gt;
&lt;br /&gt;
{{Definition | A &#039;&#039;2-category&#039;&#039; is like a category: it has objects and&lt;br /&gt;
morphisms between them. But it also has &#039;&#039;2-cells&#039;&#039;, which are&lt;br /&gt;
&#039;morphisms between morphisms&#039;: &lt;br /&gt;
[[Image:2-cat-1.png|center|A 2-cell]] &lt;br /&gt;
These&lt;br /&gt;
2-cells must compose vertically and horizontally, satisfying the&lt;br /&gt;
&#039;&#039;interchange law&#039;&#039;:&lt;br /&gt;
[[Image:2-cat-inter.png|center|Interchange law]]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
There is a more comfortable representation than the &#039;2-diagrams&#039; above.&lt;br /&gt;
In pictures:&lt;br /&gt;
[[Image:Poincare.png|center|String diagram example]]&lt;br /&gt;
In words, the idea is to consider:&lt;br /&gt;
* objects as background colors, &lt;br /&gt;
* morphisms as vertical frontiers between them, and&lt;br /&gt;
* 2-cells as labelled dots.&lt;br /&gt;
&lt;br /&gt;
Then, both compositions correspond to horizontal and vertical&lt;br /&gt;
juxtaposition, respectively.  For example, the interchange law&lt;br /&gt;
corresponds to the two ways of parsing:&lt;br /&gt;
[[Image:interchange.png|center|Interchange law in a string diagram]]&lt;br /&gt;
&lt;br /&gt;
====CAT as a 2-category====&lt;br /&gt;
&lt;br /&gt;
The prime example of a 2-category is of course Cat, the category of (small) categories. It has:&lt;br /&gt;
* objects: small categories,&lt;br /&gt;
* morphisms: functors,&lt;br /&gt;
* 2-cells: natural transformations.&lt;br /&gt;
&lt;br /&gt;
Vertical composition of 2-cells is the obvious notion of composition&lt;br /&gt;
of natural transformations.&lt;br /&gt;
&lt;br /&gt;
Define the horizontal composition:&lt;br /&gt;
[[Image:vert-comp.png|center|Vertical composition]] &lt;br /&gt;
by &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{f&#039; (\alpha_a)} f&#039; (g (a)) &lt;br /&gt;
\xrightarrow{\beta_{g (a)}} g&#039; (g (a)) &amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
or equivalently&lt;br /&gt;
 &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{\beta_{f (a)}} g&#039; (f (a)) &lt;br /&gt;
\xrightarrow{g&#039; (\alpha_a)} g&#039; (g (a)).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
The two coincide by naturality. Observe that what we have actually done is:&lt;br /&gt;
* define &#039;&#039;whiskering&#039;&#039;, i.e., composing with an identity, both to the left and to the right, and &lt;br /&gt;
* observe that the two ways of defining horizontal composition from whiskering coincide.&lt;br /&gt;
This yields an equivalent definition of 2-categories.&lt;br /&gt;
&lt;br /&gt;
===Monads===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;Free&#039;&#039; constructions in algebra: monoid, group, etc====&lt;br /&gt;
&lt;br /&gt;
====Definition of a monad====&lt;br /&gt;
&lt;br /&gt;
====Eilenberg-Moore&#039;s category of algebras====&lt;br /&gt;
&lt;br /&gt;
====Kleisli&#039;s category of free algebras====&lt;br /&gt;
&lt;br /&gt;
====The category of resolutions of a monad====&lt;br /&gt;
&lt;br /&gt;
===Adjunctions===&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Definition with hom-sets====&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Adjunctions in a 2-category====&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
====Discussion: any syntax defines the free something==== &lt;br /&gt;
The issue of &lt;br /&gt;
variable binding.&lt;br /&gt;
====Adjunction between partial orders = Galois connection====&lt;br /&gt;
====&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic====&lt;br /&gt;
====Sets/graphs and categories====&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
====Composition====&lt;br /&gt;
====Preservation of limits/colimits====&lt;br /&gt;
====Freyd&#039;s existence theorem, the locally presentable case====&lt;br /&gt;
====Beck&#039;s monadicity theorem====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Limits and Colimits==&lt;br /&gt;
&lt;br /&gt;
===Limits===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Cartesian product.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Binary product.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The product of X and Y, if it exists, is unique up to isomorphism.&#039;&#039; (with proof)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Set, Grp, Ab, Part.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Preorder, Subset(E), Prop with entailment.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Diagram. Cone. Limit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Limits in Set.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for products, pullbacks, equalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Monos as pullbacks.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The limit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; products and equalizers has &amp;quot;all&amp;quot; limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with a terminal object and all binary products and all equalizers has all finite limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Colimits===&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Cocone. Colimit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Sums in Set, Grp, Ab.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for sums, initial objects, pushouts, coequalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Epis as pushouts.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The colimit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The most general unifier (of two terms) is a coequalizer in the &amp;quot;category of substitutions&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; sums and coequalizers has &amp;quot;all&amp;quot; colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with an initial object and all binary sums and all coequalizers has all finite colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Limits, colimits and adjunctions===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A right adjoint preserves limits. A left adjoint preserves colimits.&#039;&#039; (with proof of existence)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The adjunction between Set and Grp&lt;br /&gt;
&lt;br /&gt;
===Sums and products===&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;distributive&#039;&#039; if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;extensive&#039;&#039; if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; &amp;quot;if..then..else..&amp;quot; from B=1+1 and extensivity.&lt;br /&gt;
 &lt;br /&gt;
==Monoidal categories==&lt;br /&gt;
&lt;br /&gt;
===Definition and graphical calculus===&lt;br /&gt;
&lt;br /&gt;
* Definition&lt;br /&gt;
* Graphical calculus&lt;br /&gt;
* The 2-category of monoidal categories, strong monoidal functors, and monoidal transformations&lt;br /&gt;
* Coherence and its many definitions&lt;br /&gt;
&lt;br /&gt;
===From planar to symmetric monoidal categories===&lt;br /&gt;
&lt;br /&gt;
A teaser for the whole enchilada of variations on monoidal structure.&lt;br /&gt;
&lt;br /&gt;
* Braided &lt;br /&gt;
* Balanced&lt;br /&gt;
* Symmetric&lt;br /&gt;
* Compact closed&lt;br /&gt;
* Traced monoidal categories and the Int/GoI construction&lt;br /&gt;
&lt;br /&gt;
===Monoidal categories for linear logic===&lt;br /&gt;
&lt;br /&gt;
* Linear logic &lt;br /&gt;
** Sequent calculus&lt;br /&gt;
** Intuitionnistic variant&lt;br /&gt;
** Proof nets&lt;br /&gt;
&lt;br /&gt;
* Symmetric monoidal closed categories&lt;br /&gt;
&lt;br /&gt;
* Star-autonomous categories&lt;br /&gt;
** Symmetric monoidal closed category with a dualising object&lt;br /&gt;
** Symmetric monoidal category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with:&lt;br /&gt;
*** a full and faithful contravariant endofunctor &amp;lt;math&amp;gt;\mathcal{C}^{op} \xrightarrow{(-)^*} \mathcal{C} &amp;lt;/math&amp;gt;, and&lt;br /&gt;
*** an isomorphism &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;\mathcal{C} (A \otimes B, C^*) \cong \mathcal{C} (A, (B \otimes C)^*).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* Trimble-Hughes&#039; free star-autonomous category&lt;br /&gt;
** Split star-autonomy&lt;br /&gt;
** The free star-autonomous category as a category of proof nets&lt;br /&gt;
** Trimble rewiring&lt;br /&gt;
&lt;br /&gt;
===Perspectives===&lt;br /&gt;
&lt;br /&gt;
* Premonoidal categories and side effects&lt;br /&gt;
* Products and coproducts&lt;br /&gt;
* Monoidal 2-categories, monoidal double categories.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4005</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4005"/>
		<updated>2009-03-17T10:46:11Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Other basic examples */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
* March 4. : monads, adjunctions.&lt;br /&gt;
* March 11. : limits and colimits.&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; from a category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to a category &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, noted &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, is given by:&lt;br /&gt;
* a map which sends every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to an object &amp;lt;math&amp;gt;FA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* a map which sends every morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, to a morphism &amp;lt;math&amp;gt;Ff&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}[FA, FB]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves identities, i.e., &amp;lt;math&amp;gt;F(id_A) = id_{FA}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves composition: &amp;lt;math&amp;gt;F(f \circ g) = F(f) \circ F(g)&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Take a functor &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;f, g, h&amp;lt;/math&amp;gt; three morphisms in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;f&#039; = Ff&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&#039; = Fg&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;h&#039; = Fh&amp;lt;/math&amp;gt;. When &amp;lt;math&amp;gt;h&#039; = f&#039; \circ g&#039;&amp;lt;/math&amp;gt;, can we say something interesting about &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt;?&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
# No, since &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; may not even compose! This is the case when &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; has type &amp;lt;math&amp;gt;A \to B&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;g \colon C \to D&amp;lt;/math&amp;gt;, with &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; collapsing &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; (i.e., &amp;lt;math&amp;gt;FA = FD&amp;lt;/math&amp;gt;).&lt;br /&gt;
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; be the category with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, and exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;. This is a preorder, so &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is monic. Now take &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;, and one extra morphism &amp;lt;math&amp;gt;n \colon \star \to \star&amp;lt;/math&amp;gt;, different from the identity. Because of &amp;lt;math&amp;gt;n \neq id_\star&amp;lt;/math&amp;gt;, yet &amp;lt;math&amp;gt;m \circ n = m \circ id&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is not monic in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;. The functor which sends &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, does not preserve monomorphisms.&lt;br /&gt;
# In general, the answer is (again) no. For monos, take for example the functor &amp;lt;math&amp;gt;\mathcal{C} \to \mathbf{2}&amp;lt;/math&amp;gt; which sends &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; to the identity. Yet, when &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is &#039;&#039;faithful&#039;&#039;, then &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is monic (or epic).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is faithful when, for any two morphisms &amp;lt;math&amp;gt;f, g&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;Ff = Fg&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;f=g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is injective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is full when, for any two objects &amp;lt;math&amp;gt;A, B&amp;lt;/math&amp;gt;, if &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; is a morphism &amp;lt;math&amp;gt;FA \to FB&amp;lt;/math&amp;gt;, then there exists &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;Ff = g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is surjective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; be the functor which sends:&lt;br /&gt;
* every set &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt; to the free group generated by &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* every function &amp;lt;math&amp;gt;f \colon X \to Y&amp;lt;/math&amp;gt; to a group morphism defined by: &amp;lt;math&amp;gt;Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;f\colon X \to Y&amp;lt;/math&amp;gt; be a morphism in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, then &amp;lt;math&amp;gt;Y_A(f)&amp;lt;/math&amp;gt; is expected to be a function from the set &amp;lt;math&amp;gt;\mathcal{C}[Y, A]&amp;lt;/math&amp;gt; to the set &amp;lt;math&amp;gt;\mathcal{C}[X, A]&amp;lt;/math&amp;gt;. We can take, for any morphism &amp;lt;math&amp;gt;m \in \mathcal{C}[Y,A]&amp;lt;/math&amp;gt;: &amp;lt;math&amp;gt;Y_A(f)(m) = m \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This extends &amp;lt;math&amp;gt;Y_A&amp;lt;/math&amp;gt; to a contravariant functor, since &amp;lt;math&amp;gt;Y_A(id_X) = id_{\mathcal{C}[X, A]}&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; be two functors &amp;lt;math&amp;gt;\mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;. A natural transformation &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt; from &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a morphism &amp;lt;math&amp;gt;\alpha_A \colon FA \to GA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt; for every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;,&lt;br /&gt;
* such that, for any morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;Gf \circ \alpha_A = \alpha_B \circ Ff&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
==Adjunctions and Monads==&lt;br /&gt;
&lt;br /&gt;
===Preliminaries===&lt;br /&gt;
&lt;br /&gt;
====2-categories and their diagrammatic calculus====&lt;br /&gt;
This part is just to make the definitions of monads and adjunctions&lt;br /&gt;
easier: we do not give the full details, and only intend to provide a&lt;br /&gt;
few intuitions.&lt;br /&gt;
&lt;br /&gt;
{{Definition | A &#039;&#039;2-category&#039;&#039; is like a category: it has objects and&lt;br /&gt;
morphisms between them. But it also has &#039;&#039;2-cells&#039;&#039;, which are&lt;br /&gt;
&#039;morphisms between morphisms&#039;: &lt;br /&gt;
[[Image:2-cat-1.png|center|A 2-cell]] &lt;br /&gt;
These&lt;br /&gt;
2-cells must compose vertically and horizontally, satisfying the&lt;br /&gt;
&#039;&#039;interchange law&#039;&#039;:&lt;br /&gt;
[[Image:2-cat-inter.png|center|Interchange law]]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
There is a more comfortable representation than the &#039;2-diagrams&#039; above.&lt;br /&gt;
In pictures:&lt;br /&gt;
[[Image:Poincare.png|center|String diagram example]]&lt;br /&gt;
In words, the idea is to consider:&lt;br /&gt;
* objects as background colors, &lt;br /&gt;
* morphisms as vertical frontiers between them, and&lt;br /&gt;
* 2-cells as labelled dots.&lt;br /&gt;
&lt;br /&gt;
Then, both compositions correspond to horizontal and vertical&lt;br /&gt;
juxtaposition, respectively.  For example, the interchange law&lt;br /&gt;
corresponds to the two ways of parsing:&lt;br /&gt;
[[Image:interchange.png|center|Interchange law in a string diagram]]&lt;br /&gt;
&lt;br /&gt;
====CAT as a 2-category====&lt;br /&gt;
&lt;br /&gt;
The prime example of a 2-category is of course Cat, the category of (small) categories. It has:&lt;br /&gt;
* objects: small categories,&lt;br /&gt;
* morphisms: functors,&lt;br /&gt;
* 2-cells: natural transformations.&lt;br /&gt;
&lt;br /&gt;
Vertical composition of 2-cells is the obvious notion of composition&lt;br /&gt;
of natural transformations.&lt;br /&gt;
&lt;br /&gt;
Define the horizontal composition:&lt;br /&gt;
[[Image:vert-comp.png|center|Vertical composition]] &lt;br /&gt;
by &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{f&#039; (\alpha_a)} f&#039; (g (a)) &lt;br /&gt;
\xrightarrow{\beta_{g (a)}} g&#039; (g (a)) &amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
or equivalently&lt;br /&gt;
 &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{\beta_{f (a)}} g&#039; (f (a)) &lt;br /&gt;
\xrightarrow{g&#039; (\alpha_a)} g&#039; (g (a)).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
The two coincide by naturality. Observe that what we have actually done is:&lt;br /&gt;
* define &#039;&#039;whiskering&#039;&#039;, i.e., composing with an identity, both to the left and to the right, and &lt;br /&gt;
* observe that the two ways of defining horizontal composition from whiskering coincide.&lt;br /&gt;
This yields an equivalent definition of 2-categories.&lt;br /&gt;
&lt;br /&gt;
===Monads===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;Free&#039;&#039; constructions in algebra: monoid, group, etc====&lt;br /&gt;
&lt;br /&gt;
====Definition of a monad====&lt;br /&gt;
&lt;br /&gt;
====Eilenberg-Moore&#039;s category of algebras====&lt;br /&gt;
&lt;br /&gt;
====Kleisli&#039;s category of free algebras====&lt;br /&gt;
&lt;br /&gt;
====The category of resolutions of a monad====&lt;br /&gt;
&lt;br /&gt;
===Adjunctions===&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Definition with hom-sets====&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Adjunctions in a 2-category====&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
====Discussion: any syntax defines the free something==== &lt;br /&gt;
The issue of &lt;br /&gt;
variable binding.&lt;br /&gt;
====Adjunction between partial orders = Galois connection====&lt;br /&gt;
====&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic====&lt;br /&gt;
====Sets/graphs and categories====&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
====Composition====&lt;br /&gt;
====Preservation of limits/colimits====&lt;br /&gt;
====Freyd&#039;s existence theorem, the locally presentable case====&lt;br /&gt;
====Beck&#039;s monadicity theorem====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Limits and Colimits==&lt;br /&gt;
&lt;br /&gt;
===Limits===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Cartesian product.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Binary product.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The product of X and Y, if it exists, is unique up to isomorphism.&#039;&#039; (with proof)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Set, Grp, Ab, Part.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Preorder, Subset(E), Prop with entailment.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Diagram. Cone. Limit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Limits in Set.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for products, pullbacks, equalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Monos as pullbacks.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The limit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; products and equalizers has &amp;quot;all&amp;quot; limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with a terminal object and all binary products and all equalizers has all finite limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Colimits===&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Cocone. Colimit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Sums in Set, Grp, Ab.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for sums, initial objects, pushouts, coequalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Epis as pushouts.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The colimit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The most general unifier (of two terms) is a coequalizer in the &amp;quot;category of substitutions&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; sums and coequalizers has &amp;quot;all&amp;quot; colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with an initial object and all binary sums and all coequalizers has all finite colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Limits, colimits and adjunctions===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A right adjoint preserves limits. A left adjoint preserves colimits.&#039;&#039; (with proof of existence)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The adjunction between Set and Grp&lt;br /&gt;
&lt;br /&gt;
===Sums and products===&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;distributive&#039;&#039; if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;extensive&#039;&#039; if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; &amp;quot;if..then..else..&amp;quot; from B=1+1 and extensivity.&lt;br /&gt;
 &lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4004</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4004"/>
		<updated>2009-03-17T10:21:25Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* CAT as a 2-category */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
* March 4. : monads, adjunctions.&lt;br /&gt;
* March 11. : limits and colimits.&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; from a category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to a category &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, noted &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, is given by:&lt;br /&gt;
* a map which sends every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to an object &amp;lt;math&amp;gt;FA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* a map which sends every morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, to a morphism &amp;lt;math&amp;gt;Ff&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}[FA, FB]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves identities, i.e., &amp;lt;math&amp;gt;F(id_A) = id_{FA}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves composition: &amp;lt;math&amp;gt;F(f \circ g) = F(f) \circ F(g)&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Take a functor &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;f, g, h&amp;lt;/math&amp;gt; three morphisms in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;f&#039; = Ff&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&#039; = Fg&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;h&#039; = Fh&amp;lt;/math&amp;gt;. When &amp;lt;math&amp;gt;h&#039; = f&#039; \circ g&#039;&amp;lt;/math&amp;gt;, can we say something interesting about &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt;?&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
# No, since &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; may not even compose! This is the case when &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; has type &amp;lt;math&amp;gt;A \to B&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;g \colon C \to D&amp;lt;/math&amp;gt;, with &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; collapsing &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; (i.e., &amp;lt;math&amp;gt;FA = FD&amp;lt;/math&amp;gt;).&lt;br /&gt;
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; be the category with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, and exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;. This is a preorder, so &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is monic. Now take &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;, and one extra morphism &amp;lt;math&amp;gt;n \colon \star \to \star&amp;lt;/math&amp;gt;, different from the identity. Because of &amp;lt;math&amp;gt;n \neq id_\star&amp;lt;/math&amp;gt;, yet &amp;lt;math&amp;gt;m \circ n = m \circ id&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is not monic in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;. The functor which sends &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, does not preserve monomorphisms.&lt;br /&gt;
# In general, the answer is (again) no. For monos, take for example the functor &amp;lt;math&amp;gt;\mathcal{C} \to \mathbf{2}&amp;lt;/math&amp;gt; which sends &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; to the identity. Yet, when &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is &#039;&#039;faithful&#039;&#039;, then &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is monic (or epic).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is faithful when, for any two morphisms &amp;lt;math&amp;gt;f, g&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;Ff = Fg&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;f=g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is injective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is full when, for any two objects &amp;lt;math&amp;gt;A, B&amp;lt;/math&amp;gt;, if &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; is a morphism &amp;lt;math&amp;gt;FA \to FB&amp;lt;/math&amp;gt;, then there exists &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;Ff = g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is surjective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; be the functor which sends:&lt;br /&gt;
* every set &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt; to the free group generated by &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* every function &amp;lt;math&amp;gt;f \colon X \to Y&amp;lt;/math&amp;gt; to a group morphism defined by: &amp;lt;math&amp;gt;Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;f\colon X \to Y&amp;lt;/math&amp;gt; be a morphism in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, then &amp;lt;math&amp;gt;Y_A(f)&amp;lt;/math&amp;gt; is expected to be a function from the set &amp;lt;math&amp;gt;\mathcal{C}[Y, A]&amp;lt;/math&amp;gt; to the set &amp;lt;math&amp;gt;\mathcal{C}[X, A]&amp;lt;/math&amp;gt;. We can take, for any morphism &amp;lt;math&amp;gt;m \in \mathcal{C}[Y,A]&amp;lt;/math&amp;gt;: &amp;lt;math&amp;gt;Y_A(f)(m) = m \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This extends &amp;lt;math&amp;gt;Y_A&amp;lt;/math&amp;gt; to a contravariant functor, since &amp;lt;math&amp;gt;Y_A(id_X) = id_{\mathcal{C}[X, A]}&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; be two functors &amp;lt;math&amp;gt;\mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;. A natural transformation &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt; from &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a morphism &amp;lt;math&amp;gt;\alpha_A \colon FA \to GA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt; for every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;,&lt;br /&gt;
* such that, for any morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;Gf \circ \alpha_A = \alpha_B \circ Ff&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
==Adjunctions and Monads==&lt;br /&gt;
&lt;br /&gt;
===Preliminaries===&lt;br /&gt;
&lt;br /&gt;
====2-categories and their diagrammatic calculus====&lt;br /&gt;
This part is just to make the definitions of monads and adjunctions&lt;br /&gt;
easier: we do not give the full details, and only intend to provide a&lt;br /&gt;
few intuitions.&lt;br /&gt;
&lt;br /&gt;
{{Definition | A &#039;&#039;2-category&#039;&#039; is like a category: it has objects and&lt;br /&gt;
morphisms between them. But it also has &#039;&#039;2-cells&#039;&#039;, which are&lt;br /&gt;
&#039;morphisms between morphisms&#039;: &lt;br /&gt;
[[Image:2-cat-1.png|center|A 2-cell]] &lt;br /&gt;
These&lt;br /&gt;
2-cells must compose vertically and horizontally, satisfying the&lt;br /&gt;
&#039;&#039;interchange law&#039;&#039;:&lt;br /&gt;
[[Image:2-cat-inter.png|center|Interchange law]]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
There is a more comfortable representation than the &#039;2-diagrams&#039; above.&lt;br /&gt;
In pictures:&lt;br /&gt;
[[Image:Poincare.png|center|String diagram example]]&lt;br /&gt;
In words, the idea is to consider:&lt;br /&gt;
* objects as background colors, &lt;br /&gt;
* morphisms as vertical frontiers between them, and&lt;br /&gt;
* 2-cells as labelled dots.&lt;br /&gt;
&lt;br /&gt;
Then, both compositions correspond to horizontal and vertical&lt;br /&gt;
juxtaposition, respectively.  For example, the interchange law&lt;br /&gt;
corresponds to the two ways of parsing:&lt;br /&gt;
[[Image:interchange.png|center|Interchange law in a string diagram]]&lt;br /&gt;
&lt;br /&gt;
====CAT as a 2-category====&lt;br /&gt;
&lt;br /&gt;
The prime example of a 2-category is of course Cat, the category of (small) categories. It has:&lt;br /&gt;
* objects: small categories,&lt;br /&gt;
* morphisms: functors,&lt;br /&gt;
* 2-cells: natural transformations.&lt;br /&gt;
&lt;br /&gt;
Vertical composition of 2-cells is the obvious notion of composition&lt;br /&gt;
of natural transformations.&lt;br /&gt;
&lt;br /&gt;
Define the horizontal composition:&lt;br /&gt;
[[Image:vert-comp.png|center|Vertical composition]] &lt;br /&gt;
by &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{f&#039; (\alpha_a)} f&#039; (g (a)) &lt;br /&gt;
\xrightarrow{\beta_{g (a)}} g&#039; (g (a)) &amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
or equivalently&lt;br /&gt;
 &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;&lt;br /&gt;
(\beta \bullet \alpha)_a = f&#039; (f (a)) \xrightarrow{\beta_{f (a)}} g&#039; (f (a)) &lt;br /&gt;
\xrightarrow{g&#039; (\alpha_a)} g&#039; (g (a)).&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
The two coincide by naturality. Observe that what we have actually done is:&lt;br /&gt;
* define &#039;&#039;whiskering&#039;&#039;, i.e., composing with an identity, both to the left and to the right, and &lt;br /&gt;
* observe that the two ways of defining horizontal composition from whiskering coincide.&lt;br /&gt;
This yields an equivalent definition of 2-categories.&lt;br /&gt;
&lt;br /&gt;
===Monads===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;Free&#039;&#039; constructions in algebra: monoid, group, etc====&lt;br /&gt;
&lt;br /&gt;
====Definition of a monad====&lt;br /&gt;
&lt;br /&gt;
====Eilenberg-Moore&#039;s category of algebras====&lt;br /&gt;
&lt;br /&gt;
====Kleisli&#039;s category of free algebras====&lt;br /&gt;
&lt;br /&gt;
====The category of resolutions of a monad====&lt;br /&gt;
&lt;br /&gt;
===Adjunctions===&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Definition with hom-sets====&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Adjunctions in a 2-category====&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
====Discussion: any syntax defines the free something==== The issue of &lt;br /&gt;
variable binding.&lt;br /&gt;
====Adjunction between partial orders = Galois connection====&lt;br /&gt;
====&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic====&lt;br /&gt;
====Sets/graphs and categories====&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
====Composition====&lt;br /&gt;
====Preservation of limits/colimits====&lt;br /&gt;
====Freyd&#039;s existence theorem, the locally presentable case====&lt;br /&gt;
====Beck&#039;s monadicity theorem====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Limits and Colimits==&lt;br /&gt;
&lt;br /&gt;
===Limits===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Cartesian product.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Binary product.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The product of X and Y, if it exists, is unique up to isomorphism.&#039;&#039; (with proof)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Set, Grp, Ab, Part.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Preorder, Subset(E), Prop with entailment.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Diagram. Cone. Limit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Limits in Set.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for products, pullbacks, equalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Monos as pullbacks.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The limit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; products and equalizers has &amp;quot;all&amp;quot; limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with a terminal object and all binary products and all equalizers has all finite limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Colimits===&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Cocone. Colimit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Sums in Set, Grp, Ab.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for sums, initial objects, pushouts, coequalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Epis as pushouts.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The colimit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The most general unifier (of two terms) is a coequalizer in the &amp;quot;category of substitutions&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; sums and coequalizers has &amp;quot;all&amp;quot; colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with an initial object and all binary sums and all coequalizers has all finite colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Limits, colimits and adjunctions===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A right adjoint preserves limits. A left adjoint preserves colimits.&#039;&#039; (with proof of existence)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The adjunction between Set and Grp&lt;br /&gt;
&lt;br /&gt;
===Sums and products===&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;distributive&#039;&#039; if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;extensive&#039;&#039; if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; &amp;quot;if..then..else..&amp;quot; from B=1+1 and extensivity.&lt;br /&gt;
 &lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4003</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=4003"/>
		<updated>2009-03-17T10:14:31Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* 2-categories and their diagrammatic calculus */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
* March 4. : monads, adjunctions.&lt;br /&gt;
* March 11. : limits and colimits.&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; from a category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to a category &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, noted &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, is given by:&lt;br /&gt;
* a map which sends every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to an object &amp;lt;math&amp;gt;FA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* a map which sends every morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, to a morphism &amp;lt;math&amp;gt;Ff&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}[FA, FB]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves identities, i.e., &amp;lt;math&amp;gt;F(id_A) = id_{FA}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves composition: &amp;lt;math&amp;gt;F(f \circ g) = F(f) \circ F(g)&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Take a functor &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;f, g, h&amp;lt;/math&amp;gt; three morphisms in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;f&#039; = Ff&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&#039; = Fg&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;h&#039; = Fh&amp;lt;/math&amp;gt;. When &amp;lt;math&amp;gt;h&#039; = f&#039; \circ g&#039;&amp;lt;/math&amp;gt;, can we say something interesting about &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt;?&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
# No, since &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; may not even compose! This is the case when &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; has type &amp;lt;math&amp;gt;A \to B&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;g \colon C \to D&amp;lt;/math&amp;gt;, with &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; collapsing &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; (i.e., &amp;lt;math&amp;gt;FA = FD&amp;lt;/math&amp;gt;).&lt;br /&gt;
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; be the category with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, and exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;. This is a preorder, so &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is monic. Now take &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;, and one extra morphism &amp;lt;math&amp;gt;n \colon \star \to \star&amp;lt;/math&amp;gt;, different from the identity. Because of &amp;lt;math&amp;gt;n \neq id_\star&amp;lt;/math&amp;gt;, yet &amp;lt;math&amp;gt;m \circ n = m \circ id&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is not monic in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;. The functor which sends &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, does not preserve monomorphisms.&lt;br /&gt;
# In general, the answer is (again) no. For monos, take for example the functor &amp;lt;math&amp;gt;\mathcal{C} \to \mathbf{2}&amp;lt;/math&amp;gt; which sends &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; to the identity. Yet, when &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is &#039;&#039;faithful&#039;&#039;, then &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is monic (or epic).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is faithful when, for any two morphisms &amp;lt;math&amp;gt;f, g&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;Ff = Fg&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;f=g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is injective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is full when, for any two objects &amp;lt;math&amp;gt;A, B&amp;lt;/math&amp;gt;, if &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; is a morphism &amp;lt;math&amp;gt;FA \to FB&amp;lt;/math&amp;gt;, then there exists &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;Ff = g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is surjective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; be the functor which sends:&lt;br /&gt;
* every set &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt; to the free group generated by &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* every function &amp;lt;math&amp;gt;f \colon X \to Y&amp;lt;/math&amp;gt; to a group morphism defined by: &amp;lt;math&amp;gt;Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;f\colon X \to Y&amp;lt;/math&amp;gt; be a morphism in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, then &amp;lt;math&amp;gt;Y_A(f)&amp;lt;/math&amp;gt; is expected to be a function from the set &amp;lt;math&amp;gt;\mathcal{C}[Y, A]&amp;lt;/math&amp;gt; to the set &amp;lt;math&amp;gt;\mathcal{C}[X, A]&amp;lt;/math&amp;gt;. We can take, for any morphism &amp;lt;math&amp;gt;m \in \mathcal{C}[Y,A]&amp;lt;/math&amp;gt;: &amp;lt;math&amp;gt;Y_A(f)(m) = m \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This extends &amp;lt;math&amp;gt;Y_A&amp;lt;/math&amp;gt; to a contravariant functor, since &amp;lt;math&amp;gt;Y_A(id_X) = id_{\mathcal{C}[X, A]}&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; be two functors &amp;lt;math&amp;gt;\mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;. A natural transformation &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt; from &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a morphism &amp;lt;math&amp;gt;\alpha_A \colon FA \to GA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt; for every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;,&lt;br /&gt;
* such that, for any morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;Gf \circ \alpha_A = \alpha_B \circ Ff&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
==Adjunctions and Monads==&lt;br /&gt;
&lt;br /&gt;
===Preliminaries===&lt;br /&gt;
&lt;br /&gt;
====2-categories and their diagrammatic calculus====&lt;br /&gt;
This part is just to make the definitions of monads and adjunctions&lt;br /&gt;
easier: we do not give the full details, and only intend to provide a&lt;br /&gt;
few intuitions.&lt;br /&gt;
&lt;br /&gt;
{{Definition | A &#039;&#039;2-category&#039;&#039; is like a category: it has objects and&lt;br /&gt;
morphisms between them. But it also has &#039;&#039;2-cells&#039;&#039;, which are&lt;br /&gt;
&#039;morphisms between morphisms&#039;: &lt;br /&gt;
[[Image:2-cat-1.png|center|A 2-cell]] &lt;br /&gt;
These&lt;br /&gt;
2-cells must compose vertically and horizontally, satisfying the&lt;br /&gt;
&#039;&#039;interchange law&#039;&#039;:&lt;br /&gt;
[[Image:2-cat-inter.png|center|Interchange law]]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
There is a more comfortable representation than the &#039;2-diagrams&#039; above.&lt;br /&gt;
In pictures:&lt;br /&gt;
[[Image:Poincare.png|center|String diagram example]]&lt;br /&gt;
In words, the idea is to consider:&lt;br /&gt;
* objects as background colors, &lt;br /&gt;
* morphisms as vertical frontiers between them, and&lt;br /&gt;
* 2-cells as labelled dots.&lt;br /&gt;
&lt;br /&gt;
Then, both compositions correspond to horizontal and vertical&lt;br /&gt;
juxtaposition, respectively.  For example, the interchange law&lt;br /&gt;
corresponds to the two ways of parsing:&lt;br /&gt;
[[Image:interchange.png|center|Interchange law in a string diagram]]&lt;br /&gt;
&lt;br /&gt;
====CAT as a 2-category====&lt;br /&gt;
&lt;br /&gt;
===Monads===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;Free&#039;&#039; constructions in algebra: monoid, group, etc====&lt;br /&gt;
&lt;br /&gt;
====Definition of a monad====&lt;br /&gt;
&lt;br /&gt;
====Eilenberg-Moore&#039;s category of algebras====&lt;br /&gt;
&lt;br /&gt;
====Kleisli&#039;s category of free algebras====&lt;br /&gt;
&lt;br /&gt;
====The category of resolutions of a monad====&lt;br /&gt;
&lt;br /&gt;
===Adjunctions===&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Definition with hom-sets====&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Adjunctions in a 2-category====&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
====Discussion: any syntax defines the free something==== The issue of &lt;br /&gt;
variable binding.&lt;br /&gt;
====Adjunction between partial orders = Galois connection====&lt;br /&gt;
====&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic====&lt;br /&gt;
====Sets/graphs and categories====&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
====Composition====&lt;br /&gt;
====Preservation of limits/colimits====&lt;br /&gt;
====Freyd&#039;s existence theorem, the locally presentable case====&lt;br /&gt;
====Beck&#039;s monadicity theorem====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Limits and Colimits==&lt;br /&gt;
&lt;br /&gt;
===Limits===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Cartesian product.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Binary product.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The product of X and Y, if it exists, is unique up to isomorphism.&#039;&#039; (with proof)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Set, Grp, Ab, Part.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Preorder, Subset(E), Prop with entailment.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Diagram. Cone. Limit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Limits in Set.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for products, pullbacks, equalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Monos as pullbacks.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The limit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; products and equalizers has &amp;quot;all&amp;quot; limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with a terminal object and all binary products and all equalizers has all finite limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Colimits===&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Cocone. Colimit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Sums in Set, Grp, Ab.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for sums, initial objects, pushouts, coequalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Epis as pushouts.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The colimit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The most general unifier (of two terms) is a coequalizer in the &amp;quot;category of substitutions&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; sums and coequalizers has &amp;quot;all&amp;quot; colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with an initial object and all binary sums and all coequalizers has all finite colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Limits, colimits and adjunctions===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A right adjoint preserves limits. A left adjoint preserves colimits.&#039;&#039; (with proof of existence)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The adjunction between Set and Grp&lt;br /&gt;
&lt;br /&gt;
===Sums and products===&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;distributive&#039;&#039; if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;extensive&#039;&#039; if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; &amp;quot;if..then..else..&amp;quot; from B=1+1 and extensivity.&lt;br /&gt;
 &lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Vert-comp.png&amp;diff=4002</id>
		<title>Fichier:Vert-comp.png</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Vert-comp.png&amp;diff=4002"/>
		<updated>2009-03-17T10:14:24Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Interchange.png&amp;diff=4001</id>
		<title>Fichier:Interchange.png</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Interchange.png&amp;diff=4001"/>
		<updated>2009-03-17T10:07:38Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Poincare.png&amp;diff=4000</id>
		<title>Fichier:Poincare.png</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Poincare.png&amp;diff=4000"/>
		<updated>2009-03-17T09:55:21Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:2-cat-inter.png&amp;diff=3999</id>
		<title>Fichier:2-cat-inter.png</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:2-cat-inter.png&amp;diff=3999"/>
		<updated>2009-03-17T09:42:51Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:2-cat-inter.pdf&amp;diff=3998</id>
		<title>Fichier:2-cat-inter.pdf</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:2-cat-inter.pdf&amp;diff=3998"/>
		<updated>2009-03-17T09:41:07Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:2-cat-1.png&amp;diff=3997</id>
		<title>Fichier:2-cat-1.png</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:2-cat-1.png&amp;diff=3997"/>
		<updated>2009-03-17T09:40:52Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3996</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3996"/>
		<updated>2009-03-17T09:24:49Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
* March 4. : monads, adjunctions.&lt;br /&gt;
* March 11. : limits and colimits.&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
Informally, a functor is a map between two categories which somehow preserves the structure of categories (namely, composition).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; from a category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to a category &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, noted &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, is given by:&lt;br /&gt;
* a map which sends every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to an object &amp;lt;math&amp;gt;FA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* a map which sends every morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, to a morphism &amp;lt;math&amp;gt;Ff&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}[FA, FB]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves identities, i.e., &amp;lt;math&amp;gt;F(id_A) = id_{FA}&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; preserves composition: &amp;lt;math&amp;gt;F(f \circ g) = F(f) \circ F(g)&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Take a functor &amp;lt;math&amp;gt;F \colon \mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;f, g, h&amp;lt;/math&amp;gt; three morphisms in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;f&#039; = Ff&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&#039; = Fg&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;h&#039; = Fh&amp;lt;/math&amp;gt;. When &amp;lt;math&amp;gt;h&#039; = f&#039; \circ g&#039;&amp;lt;/math&amp;gt;, can we say something interesting about &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt;?&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
# No, since &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; may not even compose! This is the case when &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; has type &amp;lt;math&amp;gt;A \to B&amp;lt;/math&amp;gt;, and &amp;lt;math&amp;gt;g \colon C \to D&amp;lt;/math&amp;gt;, with &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; collapsing &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; (i.e., &amp;lt;math&amp;gt;FA = FD&amp;lt;/math&amp;gt;).&lt;br /&gt;
# Functors in general do not preserve mono- nor epimorphisms. We build a counter-example for monomorphisms. Let &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; be the category with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, and exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;. This is a preorder, so &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is monic. Now take &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; with two objects &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt;, exactly one morphism &amp;lt;math&amp;gt;m \colon \star \to \bullet&amp;lt;/math&amp;gt;, and one extra morphism &amp;lt;math&amp;gt;n \colon \star \to \star&amp;lt;/math&amp;gt;, different from the identity. Because of &amp;lt;math&amp;gt;n \neq id_\star&amp;lt;/math&amp;gt;, yet &amp;lt;math&amp;gt;m \circ n = m \circ id&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; is not monic in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;. The functor which sends &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\star&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;\bullet&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathbf{2}&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;m&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, does not preserve monomorphisms.&lt;br /&gt;
# In general, the answer is (again) no. For monos, take for example the functor &amp;lt;math&amp;gt;\mathcal{C} \to \mathbf{2}&amp;lt;/math&amp;gt; which sends &amp;lt;math&amp;gt;n&amp;lt;/math&amp;gt; to the identity. Yet, when &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is &#039;&#039;faithful&#039;&#039;, then &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is monic (or epic).&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is faithful when, for any two morphisms &amp;lt;math&amp;gt;f, g&amp;lt;/math&amp;gt;, &amp;lt;math&amp;gt;Ff = Fg&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;f=g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is injective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
{{Definition |&lt;br /&gt;
A functor &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is full when, for any two objects &amp;lt;math&amp;gt;A, B&amp;lt;/math&amp;gt;, if &amp;lt;math&amp;gt;g&amp;lt;/math&amp;gt; is a morphism &amp;lt;math&amp;gt;FA \to FB&amp;lt;/math&amp;gt;, then there exists &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;Ff = g&amp;lt;/math&amp;gt; (&amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; is surjective on morphisms).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; be the functor which sends:&lt;br /&gt;
* every set &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt; to the free group generated by &amp;lt;math&amp;gt;X&amp;lt;/math&amp;gt;, and&lt;br /&gt;
* every function &amp;lt;math&amp;gt;f \colon X \to Y&amp;lt;/math&amp;gt; to a group morphism defined by: &amp;lt;math&amp;gt;Ff(x_1^{\alpha_1}\times\dots\times x_k^{\alpha_k})=f(x_1)^{\alpha_1} \times \dots \times f(x_k)^{\alpha_k}&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Answer&amp;lt;/u&amp;gt;&lt;br /&gt;
Let &amp;lt;math&amp;gt;f\colon X \to Y&amp;lt;/math&amp;gt; be a morphism in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, then &amp;lt;math&amp;gt;Y_A(f)&amp;lt;/math&amp;gt; is expected to be a function from the set &amp;lt;math&amp;gt;\mathcal{C}[Y, A]&amp;lt;/math&amp;gt; to the set &amp;lt;math&amp;gt;\mathcal{C}[X, A]&amp;lt;/math&amp;gt;. We can take, for any morphism &amp;lt;math&amp;gt;m \in \mathcal{C}[Y,A]&amp;lt;/math&amp;gt;: &amp;lt;math&amp;gt;Y_A(f)(m) = m \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
This extends &amp;lt;math&amp;gt;Y_A&amp;lt;/math&amp;gt; to a contravariant functor, since &amp;lt;math&amp;gt;Y_A(id_X) = id_{\mathcal{C}[X, A]}&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;Y_A(f \circ g)(m) = m \circ (f \circ g) = (m \circ f) \circ g = (Y_A(g) \circ Y_A(f))(m)&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
Let &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; be two functors &amp;lt;math&amp;gt;\mathcal{C} \to \mathcal{D}&amp;lt;/math&amp;gt;. A natural transformation &amp;lt;math&amp;gt;\alpha&amp;lt;/math&amp;gt; from &amp;lt;math&amp;gt;F&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;G&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a morphism &amp;lt;math&amp;gt;\alpha_A \colon FA \to GA&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{D}&amp;lt;/math&amp;gt; for every object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; in &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;,&lt;br /&gt;
* such that, for any morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;Gf \circ \alpha_A = \alpha_B \circ Ff&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
==Adjunctions and Monads==&lt;br /&gt;
&lt;br /&gt;
===Preliminaries===&lt;br /&gt;
&lt;br /&gt;
====2-categories and their diagrammatic calculus====&lt;br /&gt;
&lt;br /&gt;
====CAT as a 2-category====&lt;br /&gt;
&lt;br /&gt;
===Monads===&lt;br /&gt;
&lt;br /&gt;
====&#039;&#039;Free&#039;&#039; constructions in algebra: monoid, group, etc====&lt;br /&gt;
&lt;br /&gt;
====Definition of a monad====&lt;br /&gt;
&lt;br /&gt;
====Eilenberg-Moore&#039;s category of algebras====&lt;br /&gt;
&lt;br /&gt;
====Kleisli&#039;s category of free algebras====&lt;br /&gt;
&lt;br /&gt;
====The category of resolutions of a monad====&lt;br /&gt;
&lt;br /&gt;
===Adjunctions===&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Definition with hom-sets====&lt;br /&gt;
&lt;br /&gt;
====Definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
====Adjunctions in a 2-category====&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
====Discussion: any syntax defines the free something==== The issue of &lt;br /&gt;
variable binding.&lt;br /&gt;
====Adjunction between partial orders = Galois connection====&lt;br /&gt;
====&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic====&lt;br /&gt;
====Sets/graphs and categories====&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
====Composition====&lt;br /&gt;
====Preservation of limits/colimits====&lt;br /&gt;
====Freyd&#039;s existence theorem, the locally presentable case====&lt;br /&gt;
====Beck&#039;s monadicity theorem====&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Limits and Colimits==&lt;br /&gt;
&lt;br /&gt;
===Limits===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Cartesian product.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Binary product.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The product of X and Y, if it exists, is unique up to isomorphism.&#039;&#039; (with proof)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Set, Grp, Ab, Part.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Preorder, Subset(E), Prop with entailment.&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Diagram. Cone. Limit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Limits in Set.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for products, pullbacks, equalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Monos as pullbacks.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The limit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; products and equalizers has &amp;quot;all&amp;quot; limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with a terminal object and all binary products and all equalizers has all finite limits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Colimits===&lt;br /&gt;
&lt;br /&gt;
{{ Definition | Cocone. Colimit.}}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Sums in Set, Grp, Ab.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Examples.&#039;&#039;&#039; Shape of diagrams for sums, initial objects, pushouts, coequalizers.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; Epis as pushouts.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;The colimit of a diagram d, if it exists, is unique up to isomorphism.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The most general unifier (of two terms) is a coequalizer in the &amp;quot;category of substitutions&amp;quot;.&lt;br /&gt;
 &lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with &amp;quot;all&amp;quot; sums and coequalizers has &amp;quot;all&amp;quot; colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A category with an initial object and all binary sums and all coequalizers has all finite colimits.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
===Limits, colimits and adjunctions===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Theorem.&#039;&#039;&#039; &#039;&#039;A right adjoint preserves limits. A left adjoint preserves colimits.&#039;&#039; (with proof of existence)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; The adjunction between Set and Grp&lt;br /&gt;
&lt;br /&gt;
===Sums and products===&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;distributive&#039;&#039; if the canonical map from AxB+AxC to Ax(B+C) is an isomorphism.&lt;br /&gt;
&lt;br /&gt;
A category is &#039;&#039;extensive&#039;&#039; if the canonical functor + from C/A x C/B to C/(A+B) is an equivalence. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example.&#039;&#039;&#039; &amp;quot;if..then..else..&amp;quot; from B=1+1 and extensivity.&lt;br /&gt;
 &lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3884</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3884"/>
		<updated>2009-03-02T13:29:19Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Adjunctions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
==Limits and colimits==&lt;br /&gt;
&lt;br /&gt;
One of the main thrusts of category theory is to define concepts by&lt;br /&gt;
their properties rather than by explicit construction. In general this&lt;br /&gt;
is just called abstraction, but in good cases, concepts are&lt;br /&gt;
&#039;&#039;defined&#039;&#039; by their properties, at least canonically if not uniquely.&lt;br /&gt;
&lt;br /&gt;
The chief example of this is binary products in &#039;&#039;&#039;Set&#039;&#039;&#039;.  The&lt;br /&gt;
product &amp;lt;math&amp;gt;A \times B&amp;lt;/math&amp;gt; of two sets &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and&lt;br /&gt;
&amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is generally thought of as the set of pairs &amp;lt;math&amp;gt; (x,&lt;br /&gt;
y) &amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;x \in A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;y \in B&amp;lt;/math&amp;gt;.  But&lt;br /&gt;
strictly speaking, or rather set-theoretically speaking, one has to&lt;br /&gt;
construct it by cautious use of the axioms of Zermelo-Fraenkel set&lt;br /&gt;
theory.&lt;br /&gt;
&lt;br /&gt;
Instead, in any category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, for any objects&lt;br /&gt;
&amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; categorists put: &lt;br /&gt;
&lt;br /&gt;
{{Definition | A&lt;br /&gt;
&#039;&#039;product&#039;&#039; of &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is an object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt;&lt;br /&gt;
with arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{\pi_1} C \xrightarrow{\pi_2} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
such that for any object &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{f} D \xrightarrow{g} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
there exists a unique arrow &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt; making the diagram&lt;br /&gt;
[[Image:prod.png|center|Universal property of product]]&lt;br /&gt;
commute, i.e., &amp;lt;math&amp;gt;\pi_1 \circ h = f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\pi_2 \circ h = g&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
The standard constructions in &#039;&#039;&#039;Set&#039;&#039;&#039; all have this property, and&lt;br /&gt;
all the non-standard ones you can think of also do, e.g., the set of&lt;br /&gt;
pairs &amp;lt;math&amp;gt; (\emptyset, x, y) &amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;x \in A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;y&lt;br /&gt;
\in B&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Conversely, any set with this property is as good as any other&lt;br /&gt;
construction of &amp;lt;math&amp;gt;A \times B&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Products are determined &#039;&#039;canonically&#039;&#039; by this property&lt;br /&gt;
property. We will give a more precise meaning to this in later&lt;br /&gt;
lectures; for now we just state:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Lemma.&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For any other product &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{p} E \xrightarrow{q} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt; of &lt;br /&gt;
&amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;, there is a unique isomorphism pair &amp;lt;math&amp;gt; (r, s) &amp;lt;/math&amp;gt; &lt;br /&gt;
such that the diagrams&lt;br /&gt;
&lt;br /&gt;
[[Image:prod-iso.png|upright=2]] and &lt;br /&gt;
[[Image:prod-iso-2.png|upright=2]]&lt;br /&gt;
&lt;br /&gt;
commute. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
===First examples and definition===&lt;br /&gt;
&lt;br /&gt;
====So-called &#039;&#039;free&#039;&#039; constructions in algebra: monoid, group, etc====&lt;br /&gt;
====Their universal property, the underlying functor====&lt;br /&gt;
====The isomorphism between hom-sets====&lt;br /&gt;
====Its naturality====&lt;br /&gt;
====Definition====&lt;br /&gt;
====On to the definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;====&lt;br /&gt;
&lt;br /&gt;
===The simplicity behind definitions:2-categories and adjunctions therein===&lt;br /&gt;
&lt;br /&gt;
====Definition of 2-categories====&lt;br /&gt;
====String diagrams====&lt;br /&gt;
====&#039;&#039;&#039;CAT&#039;&#039;&#039; as a 2-category====&lt;br /&gt;
====Adjunctions in a 2-category====&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
====Discussion: any syntax defines the free something==== The issue of &lt;br /&gt;
variable binding.&lt;br /&gt;
====Adjunction between partial orders = Galois connection====&lt;br /&gt;
====&amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic====&lt;br /&gt;
====Sets/graphs and categories====&lt;br /&gt;
&lt;br /&gt;
===Monads and resolutions===&lt;br /&gt;
&lt;br /&gt;
====Definition of a monad====&lt;br /&gt;
====String diagrams====&lt;br /&gt;
====Every adjunction yields a monad====&lt;br /&gt;
====Example of monoids again: resolutions====&lt;br /&gt;
&lt;br /&gt;
===Monadic adjunctions===&lt;br /&gt;
&lt;br /&gt;
====The category of resolutions====&lt;br /&gt;
====Eilenberg-Moore is terminal====&lt;br /&gt;
====Kleisli is initial====&lt;br /&gt;
====Monadic adjunctions====&lt;br /&gt;
====Algebraic theories====&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
====Composing adjunctions====&lt;br /&gt;
====Preservation of limits/colimits====&lt;br /&gt;
====Freyd&#039;s existence theorem====&lt;br /&gt;
====Beck&#039;s monadicity theorem====&lt;br /&gt;
&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3883</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3883"/>
		<updated>2009-03-02T09:07:03Z</updated>

		<summary type="html">&lt;p&gt;Thirs : /* Monads and resolutions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
==Limits and colimits==&lt;br /&gt;
&lt;br /&gt;
One of the main thrusts of category theory is to define concepts by&lt;br /&gt;
their properties rather than by explicit construction. In general this&lt;br /&gt;
is just called abstraction, but in good cases, concepts are&lt;br /&gt;
&#039;&#039;defined&#039;&#039; by their properties, at least canonically if not uniquely.&lt;br /&gt;
&lt;br /&gt;
The chief example of this is binary products in &#039;&#039;&#039;Set&#039;&#039;&#039;.  The&lt;br /&gt;
product &amp;lt;math&amp;gt;A \times B&amp;lt;/math&amp;gt; of two sets &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and&lt;br /&gt;
&amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is generally thought of as the set of pairs &amp;lt;math&amp;gt; (x,&lt;br /&gt;
y) &amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;x \in A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;y \in B&amp;lt;/math&amp;gt;.  But&lt;br /&gt;
strictly speaking, or rather set-theoretically speaking, one has to&lt;br /&gt;
construct it by cautious use of the axioms of Zermelo-Fraenkel set&lt;br /&gt;
theory.&lt;br /&gt;
&lt;br /&gt;
Instead, in any category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, for any objects&lt;br /&gt;
&amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; categorists put: &lt;br /&gt;
&lt;br /&gt;
{{Definition | A&lt;br /&gt;
&#039;&#039;product&#039;&#039; of &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is an object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt;&lt;br /&gt;
with arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{\pi_1} C \xrightarrow{\pi_2} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
such that for any object &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{f} D \xrightarrow{g} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
there exists a unique arrow &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt; making the diagram&lt;br /&gt;
[[Image:prod.png|center|Universal property of product]]&lt;br /&gt;
commute, i.e., &amp;lt;math&amp;gt;\pi_1 \circ h = f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\pi_2 \circ h = g&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
The standard constructions in &#039;&#039;&#039;Set&#039;&#039;&#039; all have this property, and&lt;br /&gt;
all the non-standard ones you can think of also do, e.g., the set of&lt;br /&gt;
pairs &amp;lt;math&amp;gt; (\emptyset, x, y) &amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;x \in A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;y&lt;br /&gt;
\in B&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Conversely, any set with this property is as good as any other&lt;br /&gt;
construction of &amp;lt;math&amp;gt;A \times B&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Products are determined &#039;&#039;canonically&#039;&#039; by this property&lt;br /&gt;
property. We will give a more precise meaning to this in later&lt;br /&gt;
lectures; for now we just state:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Lemma.&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For any other product &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{p} E \xrightarrow{q} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt; of &lt;br /&gt;
&amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;, there is a unique isomorphism pair &amp;lt;math&amp;gt; (r, s) &amp;lt;/math&amp;gt; &lt;br /&gt;
such that the diagrams&lt;br /&gt;
&lt;br /&gt;
[[Image:prod-iso.png|upright=2]] and &lt;br /&gt;
[[Image:prod-iso-2.png|upright=2]]&lt;br /&gt;
&lt;br /&gt;
commute. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
===First examples and definition===&lt;br /&gt;
&lt;br /&gt;
# So-called &#039;&#039;free&#039;&#039; constructions in algebra: monoid, group, etc.&lt;br /&gt;
# Their universal property, the underlying functor.&lt;br /&gt;
# The isomorphism between hom-sets.&lt;br /&gt;
# Its naturality.&lt;br /&gt;
# Definition.&lt;br /&gt;
# On to the definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===The simplicity behind definitions:2-categories and adjunctions therein===&lt;br /&gt;
&lt;br /&gt;
# Definition of 2-categories.&lt;br /&gt;
# String diagrams.&lt;br /&gt;
# &#039;&#039;&#039;CAT&#039;&#039;&#039; as a 2-category.&lt;br /&gt;
# Adjunctions in a 2-category.&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
# Discussion: any syntax defines the free something. The issue of &lt;br /&gt;
variable binding.&lt;br /&gt;
# Adjunction between partial orders = Galois connection.&lt;br /&gt;
# &amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic.&lt;br /&gt;
# Sets/graphs and categories.&lt;br /&gt;
&lt;br /&gt;
===Monads and resolutions===&lt;br /&gt;
&lt;br /&gt;
# Definition of a monad.&lt;br /&gt;
# String diagrams.&lt;br /&gt;
# Every adjunction yields a monad.&lt;br /&gt;
# Example of monoids again: resolutions.&lt;br /&gt;
&lt;br /&gt;
===Monadic adjunctions===&lt;br /&gt;
&lt;br /&gt;
# The category of resolutions.&lt;br /&gt;
# Eilenberg-Moore is terminal.&lt;br /&gt;
# Kleisli is initial.&lt;br /&gt;
# Monadic adjunctions.&lt;br /&gt;
# Algebraic theories.&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
# Composing adjunctions.&lt;br /&gt;
# Preservation of limits/colimits.&lt;br /&gt;
# Freyd&#039;s existence theorem.&lt;br /&gt;
# Beck&#039;s monadicity theorem.&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3882</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3882"/>
		<updated>2009-03-02T09:06:20Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
==Limits and colimits==&lt;br /&gt;
&lt;br /&gt;
One of the main thrusts of category theory is to define concepts by&lt;br /&gt;
their properties rather than by explicit construction. In general this&lt;br /&gt;
is just called abstraction, but in good cases, concepts are&lt;br /&gt;
&#039;&#039;defined&#039;&#039; by their properties, at least canonically if not uniquely.&lt;br /&gt;
&lt;br /&gt;
The chief example of this is binary products in &#039;&#039;&#039;Set&#039;&#039;&#039;.  The&lt;br /&gt;
product &amp;lt;math&amp;gt;A \times B&amp;lt;/math&amp;gt; of two sets &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and&lt;br /&gt;
&amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is generally thought of as the set of pairs &amp;lt;math&amp;gt; (x,&lt;br /&gt;
y) &amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;x \in A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;y \in B&amp;lt;/math&amp;gt;.  But&lt;br /&gt;
strictly speaking, or rather set-theoretically speaking, one has to&lt;br /&gt;
construct it by cautious use of the axioms of Zermelo-Fraenkel set&lt;br /&gt;
theory.&lt;br /&gt;
&lt;br /&gt;
Instead, in any category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, for any objects&lt;br /&gt;
&amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; categorists put: &lt;br /&gt;
&lt;br /&gt;
{{Definition | A&lt;br /&gt;
&#039;&#039;product&#039;&#039; of &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is an object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt;&lt;br /&gt;
with arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{\pi_1} C \xrightarrow{\pi_2} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
such that for any object &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{f} D \xrightarrow{g} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
there exists a unique arrow &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt; making the diagram&lt;br /&gt;
[[Image:prod.png|center|Universal property of product]]&lt;br /&gt;
commute, i.e., &amp;lt;math&amp;gt;\pi_1 \circ h = f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\pi_2 \circ h = g&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
The standard constructions in &#039;&#039;&#039;Set&#039;&#039;&#039; all have this property, and&lt;br /&gt;
all the non-standard ones you can think of also do, e.g., the set of&lt;br /&gt;
pairs &amp;lt;math&amp;gt; (\emptyset, x, y) &amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;x \in A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;y&lt;br /&gt;
\in B&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Conversely, any set with this property is as good as any other&lt;br /&gt;
construction of &amp;lt;math&amp;gt;A \times B&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Products are determined &#039;&#039;canonically&#039;&#039; by this property&lt;br /&gt;
property. We will give a more precise meaning to this in later&lt;br /&gt;
lectures; for now we just state:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Lemma.&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For any other product &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{p} E \xrightarrow{q} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt; of &lt;br /&gt;
&amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;, there is a unique isomorphism pair &amp;lt;math&amp;gt; (r, s) &amp;lt;/math&amp;gt; &lt;br /&gt;
such that the diagrams&lt;br /&gt;
&lt;br /&gt;
[[Image:prod-iso.png|upright=2]] and &lt;br /&gt;
[[Image:prod-iso-2.png|upright=2]]&lt;br /&gt;
&lt;br /&gt;
commute. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
===First examples and definition===&lt;br /&gt;
&lt;br /&gt;
# So-called &#039;&#039;free&#039;&#039; constructions in algebra: monoid, group, etc.&lt;br /&gt;
# Their universal property, the underlying functor.&lt;br /&gt;
# The isomorphism between hom-sets.&lt;br /&gt;
# Its naturality.&lt;br /&gt;
# Definition.&lt;br /&gt;
# On to the definition with &amp;lt;math&amp;gt;\eta&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\epsilon&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===The simplicity behind definitions:2-categories and adjunctions therein===&lt;br /&gt;
&lt;br /&gt;
# Definition of 2-categories.&lt;br /&gt;
# String diagrams.&lt;br /&gt;
# &#039;&#039;&#039;CAT&#039;&#039;&#039; as a 2-category.&lt;br /&gt;
# Adjunctions in a 2-category.&lt;br /&gt;
&lt;br /&gt;
===Other basic examples===&lt;br /&gt;
&lt;br /&gt;
# Discussion: any syntax defines the free something. The issue of &lt;br /&gt;
variable binding.&lt;br /&gt;
# Adjunction between partial orders = Galois connection.&lt;br /&gt;
# &amp;lt;math&amp;gt;\times&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\Rightarrow&amp;lt;/math&amp;gt; in logic.&lt;br /&gt;
# Sets/graphs and categories.&lt;br /&gt;
&lt;br /&gt;
===Monads and resolutions===&lt;br /&gt;
&lt;br /&gt;
# Def of a monad&lt;br /&gt;
# String diagrams.&lt;br /&gt;
# Every adjunction yields a monad.&lt;br /&gt;
# Example of monoids again: resolutions.&lt;br /&gt;
&lt;br /&gt;
===Monadic adjunctions===&lt;br /&gt;
&lt;br /&gt;
# The category of resolutions.&lt;br /&gt;
# Eilenberg-Moore is terminal.&lt;br /&gt;
# Kleisli is initial.&lt;br /&gt;
# Monadic adjunctions.&lt;br /&gt;
# Algebraic theories.&lt;br /&gt;
&lt;br /&gt;
===Properties===&lt;br /&gt;
&lt;br /&gt;
# Composing adjunctions.&lt;br /&gt;
# Preservation of limits/colimits.&lt;br /&gt;
# Freyd&#039;s existence theorem.&lt;br /&gt;
# Beck&#039;s monadicity theorem.&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3876</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3876"/>
		<updated>2009-02-27T16:00:07Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
==Limits and colimits==&lt;br /&gt;
&lt;br /&gt;
One of the main thrusts of category theory is to define concepts by&lt;br /&gt;
their properties rather than by explicit construction. In general this&lt;br /&gt;
is just called abstraction, but in good cases, concepts are&lt;br /&gt;
&#039;&#039;defined&#039;&#039; by their properties, at least canonically if not uniquely.&lt;br /&gt;
&lt;br /&gt;
The chief example of this is binary products in &#039;&#039;&#039;Set&#039;&#039;&#039;.  The&lt;br /&gt;
product &amp;lt;math&amp;gt;A \times B&amp;lt;/math&amp;gt; of two sets &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and&lt;br /&gt;
&amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is generally thought of as the set of pairs &amp;lt;math&amp;gt; (x,&lt;br /&gt;
y) &amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;x \in A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;y \in B&amp;lt;/math&amp;gt;.  But&lt;br /&gt;
strictly speaking, or rather set-theoretically speaking, one has to&lt;br /&gt;
construct it by cautious use of the axioms of Zermelo-Fraenkel set&lt;br /&gt;
theory.&lt;br /&gt;
&lt;br /&gt;
Instead, in any category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, for any objects&lt;br /&gt;
&amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; categorists put: &lt;br /&gt;
&lt;br /&gt;
{{Definition | A&lt;br /&gt;
&#039;&#039;product&#039;&#039; of &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is an object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt;&lt;br /&gt;
with arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{\pi_1} C \xrightarrow{\pi_2} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
such that for any object &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{f} D \xrightarrow{g} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
there exists a unique arrow &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt; making the diagram&lt;br /&gt;
[[Image:prod.png|center|Universal property of product]]&lt;br /&gt;
commute, i.e., &amp;lt;math&amp;gt;\pi_1 \circ h = f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\pi_2 \circ h = g&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
The standard constructions in &#039;&#039;&#039;Set&#039;&#039;&#039; all have this property, and&lt;br /&gt;
all the non-standard ones you can think of also do, e.g., the set of&lt;br /&gt;
pairs &amp;lt;math&amp;gt; (\emptyset, x, y) &amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;x \in A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;y&lt;br /&gt;
\in B&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Conversely, any set with this property is as good as any other&lt;br /&gt;
construction of &amp;lt;math&amp;gt;A \times B&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Products are determined &#039;&#039;canonically&#039;&#039; by this property&lt;br /&gt;
property. We will give a more precise meaning to this in later&lt;br /&gt;
lectures; for now we just state:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Lemma.&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For any other product &amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{p} E \xrightarrow{q} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt; of &lt;br /&gt;
&amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;, there is a unique isomorphism pair &amp;lt;math&amp;gt; (r, s) &amp;lt;/math&amp;gt; &lt;br /&gt;
such that the diagrams&lt;br /&gt;
&lt;br /&gt;
[[Image:prod-iso.png|upright=2]] and &lt;br /&gt;
[[Image:prod-iso-2.png|upright=2]]&lt;br /&gt;
&lt;br /&gt;
commute. &lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
===Basic examples===&lt;br /&gt;
&lt;br /&gt;
===Definitions===&lt;br /&gt;
&lt;br /&gt;
===Monads and resolutions===&lt;br /&gt;
&lt;br /&gt;
===Monadic adjunctions===&lt;br /&gt;
&lt;br /&gt;
===2-categories and adjunctions therein===&lt;br /&gt;
&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Prod-iso-2.png&amp;diff=3875</id>
		<title>Fichier:Prod-iso-2.png</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Prod-iso-2.png&amp;diff=3875"/>
		<updated>2009-02-27T15:48:37Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Prod-iso.png&amp;diff=3874</id>
		<title>Fichier:Prod-iso.png</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Prod-iso.png&amp;diff=3874"/>
		<updated>2009-02-27T15:48:19Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3873</id>
		<title>Langage et concepts catégoriques pour les mathématiques et l’informatique</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Langage_et_concepts_cat%C3%A9goriques_pour_les_math%C3%A9matiques_et_l%E2%80%99informatique&amp;diff=3873"/>
		<updated>2009-02-27T15:00:35Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This is a wiki for a course at the MSTII &amp;quot;École doctorale&amp;quot; of Grenoble.&lt;br /&gt;
&lt;br /&gt;
Students are encouraged to participate by extending the wiki, adding proofs, corrections for exercices etc. To be able to modify the wiki, you need to register (upper right corner). Please use your real name...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===News===&lt;br /&gt;
&lt;br /&gt;
Courses are on wednesdays morning, 9&#039;00 to 12&#039;00 in room F218 at the &amp;quot;UFR IMAG&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* first course on the 25th of February: categories, functors, natural transformations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Basic Concepts==&lt;br /&gt;
&lt;br /&gt;
===Categories===&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A concrete category is given by:&lt;br /&gt;
* a collection of sets &#039;&#039;with structure&#039;&#039;,&lt;br /&gt;
* for any pair of such sets, a set of &#039;&#039;morphisms&#039;&#039; preserving the structure.&lt;br /&gt;
Morphisms should compose, and the identity should be a morphism.}}&lt;br /&gt;
&lt;br /&gt;
This definition is a little informal, but here are some examples:&lt;br /&gt;
* &#039;&#039;&#039;Grp&#039;&#039;&#039;: groups and group morphisms&lt;br /&gt;
* &#039;&#039;&#039;Top&#039;&#039;&#039;: topological spaces and continuous functions&lt;br /&gt;
* &#039;&#039;&#039;Ring&#039;&#039;&#039;: rings and rings morphisms&lt;br /&gt;
* &#039;&#039;&#039;Vect&#039;&#039;&#039;: vectors spaces and linear maps&lt;br /&gt;
* &#039;&#039;&#039;CPO&#039;&#039;&#039;: CPOs and continuous functions&lt;br /&gt;
* ...&lt;br /&gt;
* &#039;&#039;&#039;Set&#039;&#039;&#039;: sets and functions (&#039;&#039;&#039;ie&#039;&#039;&#039; sets with no structures, and arbitrary functions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Generalizing the definition, we obtain the official definition of category:&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
A category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is given by:&lt;br /&gt;
* a collection &amp;lt;math&amp;gt;\mathcal{C}_o&amp;lt;/math&amp;gt; of &#039;&#039;objects&#039;&#039;,  (notation: &amp;lt;math&amp;gt;A,B,C,X,Y,...&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for each pair &amp;lt;math&amp;gt;A,B&amp;lt;/math&amp;gt; of objects, a collection &amp;lt;math&amp;gt;\mathcal{C}[A,B]&amp;lt;/math&amp;gt; of &#039;&#039;morphisms from &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; to &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt;&#039;&#039;,  (notation &amp;lt;math&amp;gt; f : A\to B&amp;lt;/math&amp;gt;)&lt;br /&gt;
* for any object &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt;, a special morphism &amp;lt;math&amp;gt;i_A : A\to A&amp;lt;/math&amp;gt;&lt;br /&gt;
* for all objects &amp;lt;math&amp;gt;A,B,C&amp;lt;/math&amp;gt;, a composition &amp;lt;math&amp;gt;\circ : \mathcal{C}[B,C] \times \mathcal{C}[A,B] \to \mathcal{C}[A,C]&amp;lt;/math&amp;gt;,&lt;br /&gt;
such that:&lt;br /&gt;
* &amp;lt;math&amp;gt;f \in \mathcal{C}[A,B] \implies f\circ i_A = i_B\circ f = f&amp;lt;/math&amp;gt;&lt;br /&gt;
* &amp;lt;math&amp;gt;f\circ(g\circ h) = (f\circ g)\circ h&amp;lt;/math&amp;gt; whenever it makes sense.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
All concrete categories are categories, and here are some examples that are not obviously concrete:&lt;br /&gt;
* &#039;&#039;&#039;Graph&#039;&#039;&#039;: graphs and graph morphisms&lt;br /&gt;
* &#039;&#039;&#039;Rel&#039;&#039;&#039;: sets and relations&lt;br /&gt;
* &#039;&#039;&#039;Set×Set&#039;&#039;&#039;: pairs of sets, pairs of functions&lt;br /&gt;
* &#039;&#039;&#039;Set&amp;lt;math&amp;gt;^{op}&amp;lt;/math&amp;gt;&#039;&#039;&#039;: opposite of &#039;&#039;&#039;Set&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;P&#039;&#039;&#039;, whenever (&#039;&#039;&#039;P&#039;&#039;&#039;,&amp;lt;) is a preorder (at most one morphism between objects)&lt;br /&gt;
* &#039;&#039;&#039;M&#039;&#039;&#039;, whenever (&#039;&#039;&#039;M&#039;&#039;&#039;,e,×) is a monoid (a single object)&lt;br /&gt;
&lt;br /&gt;
We sometimes write &amp;lt;math&amp;gt;gf&amp;lt;/math&amp;gt; instead of &amp;lt;math&amp;gt;g \circ f&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
In a given category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, there are analogues of the notions of injective and surjective functions in &#039;&#039;&#039;Set&#039;&#039;&#039;. We will see that on concrete categories, they are actually slightly more general. The idea of injectivity gives rise to &#039;&#039;monomorphisms&#039;&#039;, and surjectivity gives rise to &#039;&#039;epimorphisms&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
{{Definition |&lt;br /&gt;
&lt;br /&gt;
A morphism &amp;lt;math&amp;gt;f \colon A \to B&amp;lt;/math&amp;gt; is a &#039;&#039;monomorphism&#039;&#039; iff for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon C \to A&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;fg = fh&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The morphism &amp;lt;math&amp;gt;f&amp;lt;/math&amp;gt; is an &#039;&#039;epimorphism&#039;&#039; when it is a monomorphism in &amp;lt;math&amp;gt;\mathcal{C}^{op}&amp;lt;/math&amp;gt;. Explicitly, when for all object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt; and morphisms &amp;lt;math&amp;gt;g,h \colon B \to C&amp;lt;/math&amp;gt;, we have &amp;lt;math&amp;gt;gf = hf&amp;lt;/math&amp;gt; implies &amp;lt;math&amp;gt;g = h&amp;lt;/math&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
  isomorphism&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Prove that in &#039;&#039;&#039;Set&#039;&#039;&#039;, epic is equivalent to surjective and monic is equivalent to injective.&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Ab&#039;&#039;&#039;, the category of commutative groups. (One thing is not obvious.)&lt;br /&gt;
# Prove the same thing in &#039;&#039;&#039;Grp&#039;&#039;&#039;, the category of (non necessarily commutative) groups. (One thing is not obvious at all.)&lt;br /&gt;
# Prove that &amp;lt;math&amp;gt;i : \mathbf{Z} \to \mathbf{Q}&amp;lt;/math&amp;gt; is an epimorphism in the category of rings with multiplicative neutral. (Note that it is not surjective.)&lt;br /&gt;
# In &#039;&#039;&#039;Set&#039;&#039;&#039;, we saw that &#039;&#039;f&#039;&#039; is a monic iff &amp;lt;math&amp;gt;\forall x,y : 1 \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;, where 1 is any singleton set. Can you find a set &#039;&#039;C&#039;&#039; such that &#039;&#039;f&#039;&#039; is epic iff &amp;lt;math&amp;gt;\forall p,q : B \to C, p\circ f = j\circ f \implies p=q&amp;lt;/math&amp;gt;?&lt;br /&gt;
# In &#039;&#039;&#039;Group&#039;&#039;&#039;, can you find an object playing a role similar to 1, &#039;&#039;ie&#039;&#039; a group &#039;&#039;G&#039;&#039; s.t. &#039;&#039;f&#039;&#039; is monic iff &amp;lt;math&amp;gt;\forall x,y : G \to A, f\circ x = f\circ y \implies x=y&amp;lt;/math&amp;gt;. (We saw that we cannot use the singleton group ({e},e,×) to do that...)&lt;br /&gt;
&lt;br /&gt;
===Functors===&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
# Do functors preserve monomorphisms? Do functors preserve epimorphisms?&lt;br /&gt;
# Let &#039;&#039;F&#039;&#039; be a functor and &#039;&#039;F(f) = g&#039;&#039;, if &#039;&#039;g&#039;&#039; is a mono (resp. epi), is &#039;&#039;f&#039;&#039; a mono (resp. epi)?&lt;br /&gt;
If not, try to find some simple and natural condition on the functor to make that true.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Find an &amp;quot;interesting&amp;quot; functor from &#039;&#039;&#039;Set&#039;&#039;&#039; to &#039;&#039;&#039;Group&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; is a locally small category and &#039;&#039;A&#039;&#039; one of its objects, let &amp;lt;math&amp;gt;Y_A : X \mapsto \mathcal{C}[X,A]&amp;lt;/math&amp;gt;. Show that this operation from objects of &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to sets can be extended into a contravariant functor &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt; to &#039;&#039;&#039;Set&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Natural Transformations===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 ...blabla...&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Exercice&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If &amp;lt;math&amp;gt;P(X)&amp;lt;/math&amp;gt; is the set of permutation of a (finite) set &#039;&#039;X&#039;&#039;; and &amp;lt;math&amp;gt;L(X)&amp;lt;/math&amp;gt; the set of its linear orderings, we have &amp;lt;math&amp;gt;\#(L(X)) = \#(L(X)) = n!&amp;lt;/math&amp;gt; where &amp;lt;math&amp;gt;n = \#(X)&amp;lt;/math&amp;gt;. Thus, there is a bijection (iso in &#039;&#039;&#039;Set&#039;&#039;&#039;) between &#039;&#039;P(X)&#039;&#039; and &#039;&#039;L(X)&#039;&#039;.&lt;br /&gt;
# Show that we can extend &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039; to functors from &#039;&#039;&#039;B&#039;&#039;&#039; to &#039;&#039;&#039;Set&#039;&#039;&#039;, where &#039;&#039;&#039;B&#039;&#039;&#039; is the category of finite sets and bijections,&lt;br /&gt;
# Show that there can be no natural transformation from &#039;&#039;P&#039;&#039; to &#039;&#039;L&#039;&#039;,&lt;br /&gt;
# Conclude that there is no natural isomorphism between &#039;&#039;P&#039;&#039; and &#039;&#039;L&#039;&#039;.&lt;br /&gt;
==Limits and colimits==&lt;br /&gt;
&lt;br /&gt;
One of the main thrusts of category theory is to define concepts by&lt;br /&gt;
their properties rather than by explicit construction. In general this&lt;br /&gt;
is just called abstraction, but in good cases, concepts are&lt;br /&gt;
&#039;&#039;defined&#039;&#039; by their properties, at least canonically if not uniquely.&lt;br /&gt;
&lt;br /&gt;
The chief example of this is binary products in &#039;&#039;&#039;Set&#039;&#039;&#039;.  The&lt;br /&gt;
product &amp;lt;math&amp;gt;A \times B&amp;lt;/math&amp;gt; of two sets &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and&lt;br /&gt;
&amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is generally thought of as the set of pairs &amp;lt;math&amp;gt; (x,&lt;br /&gt;
y) &amp;lt;/math&amp;gt; with &amp;lt;math&amp;gt;x \in A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;y \in B&amp;lt;/math&amp;gt;.  But&lt;br /&gt;
strictly speaking, or rather set-theoretically speaking, one has to&lt;br /&gt;
construct it by cautious use of the axioms of Zermelo-Fraenkel set&lt;br /&gt;
theory.&lt;br /&gt;
&lt;br /&gt;
Instead, in any category &amp;lt;math&amp;gt;\mathcal{C}&amp;lt;/math&amp;gt;, for any objects&lt;br /&gt;
&amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; categorists put: &lt;br /&gt;
&lt;br /&gt;
{{Definition | A&lt;br /&gt;
&#039;&#039;product&#039;&#039; of &amp;lt;math&amp;gt;A&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;B&amp;lt;/math&amp;gt; is an object &amp;lt;math&amp;gt;C&amp;lt;/math&amp;gt;&lt;br /&gt;
with arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{\pi_1} C \xrightarrow{\pi_2} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
such that for any object &amp;lt;math&amp;gt;D&amp;lt;/math&amp;gt; and arrows&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;math&amp;gt;A \xleftarrow{f} D \xrightarrow{g} B&amp;lt;/math&amp;gt;&amp;lt;/center&amp;gt;&lt;br /&gt;
there exists a unique arrow &amp;lt;math&amp;gt;h&amp;lt;/math&amp;gt; making the diagram&lt;br /&gt;
[[Image:prod.png|center|Universal property of product]]&lt;br /&gt;
commute, i.e., &amp;lt;math&amp;gt;\pi_1 \circ h = f&amp;lt;/math&amp;gt; and &amp;lt;math&amp;gt;\pi_2 \circ h = g&amp;lt;/math&amp;gt;.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Adjunctions==&lt;br /&gt;
&lt;br /&gt;
===Basic examples===&lt;br /&gt;
&lt;br /&gt;
===Definitions===&lt;br /&gt;
&lt;br /&gt;
===Monads and resolutions===&lt;br /&gt;
&lt;br /&gt;
===Monadic adjunctions===&lt;br /&gt;
&lt;br /&gt;
===2-categories and adjunctions therein===&lt;br /&gt;
&lt;br /&gt;
==Course Complements, references==&lt;br /&gt;
&lt;br /&gt;
One of the best books about category theory is&lt;br /&gt;
* Saunder MacLane, &#039;&#039;&amp;quot;Categories for the Working Mathematician&amp;quot;&#039;&#039;.&lt;br /&gt;
It is a little &amp;quot;dry&amp;quot;, in the sense that learning categories from it is not the easiest task on earth, but it still is one of the best references.&lt;br /&gt;
&lt;br /&gt;
I haven&#039;t really read it carefully, but here is [http://en.wikipedia.org/wiki/Category_theory what Wikipedia has to say on category theory].&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
	<entry>
		<id>http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Prod.png&amp;diff=3872</id>
		<title>Fichier:Prod.png</title>
		<link rel="alternate" type="text/html" href="http://os-vps418.infomaniak.ch:1250/mediawiki/index.php?title=Fichier:Prod.png&amp;diff=3872"/>
		<updated>2009-02-27T14:57:18Z</updated>

		<summary type="html">&lt;p&gt;Thirs : &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Thirs</name></author>
	</entry>
</feed>