Gluing together proof environments: Canonical extensions of LF type theories featuring locks

© F. Honsell, L. Liquori, P. Maksimovic, I. Scagnetto This work is licensed under the Creative Commons Attribution License.We present two extensions of the LF Constructive Type Theory featuring monadic locks. A lock is a monadic type construct that captures the effect of an external call to an oracle. Such calls are the basic tool for gluing together diverse Type Theories and proof development environments. The oracle can be invoked either to check that a constraint holds or to provide a suitable witness. The systems are presented in the canonical style developed by the CMU School. The first system, CLLF/p,is the canonical version of the system LLF p, presented earlier by the authors. The second system, CLLF p?, features the possibility of invoking the oracle to obtain a witness satisfying a given constraint. We discuss encodings of Fitch-Prawitz Set theory, call-by-value λ-calculi, and systems of Light Linear Logic. Finally, we show how to use Fitch-Prawitz Set Theory to define a type system that types precisely the strongly normalizing terms

A Type Checker for a Logical Framework with Union and Intersection Types

We present the syntax, semantics, and typing rules of Bull, a prototype theorem prover based on the Delta-Framework, i.e. a fully-typed lambda-calculus decorated with union and intersection types, as described in previous papers by the authors. Bull also implements a subtyping algorithm for the Type Theory Xi of Barbanera-Dezani-de'Liguoro. Bull has a command-line interface where the user can declare axioms, terms, and perform computations and some basic terminal-style features like error pretty-printing, subexpressions highlighting, and file loading. Moreover, it can typecheck a proof or normalize it. These terms can be incomplete, therefore the typechecking algorithm uses unification to try to construct the missing subterms. Bull uses the syntax of Berardi's Pure Type Systems to improve the compactness and the modularity of the kernel. Abstract and concrete syntax are mostly aligned and similar to the concrete syntax of Coq. Bull uses a higher-order unification algorithm for terms, while typechecking and partial type inference are done by a bidirectional refinement algorithm, similar to the one found in Matita and Beluga. The refinement can be split into two parts: the essence refinement and the typing refinement. Binders are implemented using commonly-used de Bruijn indices. We have defined a concrete language syntax that will allow the user to write Delta-terms. We have defined the reduction rules and an evaluator. We have implemented from scratch a refiner which does partial typechecking and type reconstruction. We have experimented Bull with classical examples of the intersection and union literature, such as the ones formalized by Pfenning with his Refinement Types in LF. We hope that this research vein could be useful to experiment, in a proof theoretical setting, forms of polymorphism alternatives to Girard's parametric one

Improving Resource Discovery in the Arigatoni Overlay Network

International audienceArigatoni is a structured multi-layer overlay network providing various services with variable guarantees, and promoting an intermittent participation to the virtual organization where peers can appear, disappear and organize themselves dynamically. Arigatoni mainly concerns with how resources are declared and discovered in the overlay, allowing global computers to make a secure, PKI-based, use of global aggregated computational power, storage, information resources, etc. Arigatoni provides fully decentralized, asynchronous and scalable resource discovery, and provides mechanisms for dealing with dynamic virtual organizations. This paper introduces a non trivial improvement of the original resource discovery protocol by allowing to register and to ask for multiple instances. Simulations show that it is efficient and scalable

Logical Networks: Self-organizing Overlay Networks and Overlay Computing Systems: [EPI Proposal V2.0]

Contents 1 Team on March 15, 2010 ...........................................42 Capsule ...........................................52.1 Slogan and logo............................................ 5 2.2 One equation fits all and keywords ................................. 6 2.3 How to read this proposal ...................................... 63 Vertical view ...........................................63.1 Panorama............................................... 6 3.2 General definitions .......................................... 8 3.3 Virtual organization ......................................... 9 3.4 Execution model ........................................... 94 Horizontal view ...............................................94.1 Panorama............................................... 94.2 Arigatoni overlay network ...................................... 10 4.2.1 Arigatoni units........................................ 10 4.2.2 Virtual organizations in Arigatoni ............................. 12 4.2.3 Resource discovery protocol (RDP)............................. 12 4.2.4 Virtual Intermittent Protocol (VIP) ............................ 13 4.2.5 iNeu: librairies for network computing........................... 144.3 Babelchord, a DHT’s tower ..................................... 144.4 Synapse,interconnecting heterogeneous overlay networks. . . . . . . . . . . . . . . . . . . . . 154.5 Cross-layer overlay design for geo-sensible applications . . . . . . . . . . . . . . . . . . . . . . 175 Diagonal view...............................................175.1 Panorama............................................... 17 5.2 Trees versus graphs: a conflict without a cause .......................... 17 5.3 Fault tolerance ............................................ 18 5.4 Parametricity and universality ................................... 18 5.5 Social networking........................................... 19 5.6 Choice of development platform................................... 19 5.7 Quality metrics for an overlay computer .............................. 19 5.8 Trust and security .......................................... 20 5.9 New models of computations .................................... 216 Topics and time line...............................................226.1 Panorama............................................... 226.2 Topicview............................................... 22 6.2.1 Vertical issues......................................... 22 6.2.2 Horizontal issues ....................................... 22 6.2.3 Diagonalissues........................................ 236.3 Timeview............................................... 23 6.3.1 Short-term .......................................... 23 6.3.2 Medium-term......................................... 24 6.3.3 Long-term........................................... 247 Potential application domains ...........................................247.1 Panorama............................................... 24 7.2 P2P social networks ......................................... 25 7.3 Overlay computer for mobile ad hoc networks........................... 25 7.4 OverStic: the mesh overlay network in Sophia Antipolis ..................... 27 7.5 Reducing the Digital Divide..................................... 28 7.6 GRID applications: scenario for seismic monitoring ....................... 29 7.7 Interconnection of heterogeneous overlay networks ........................ 30 7.8 Toward an overlay network of things (RFID) ........................... 318 Software ...........................................328.1 Panorama............................................... 328.2 Prototype software.......................................... 32 8.2.1 Arigatoni simulator ..................................... 32 8.2.2 Ariwheels........................................... 32 8.2.3 BabelChord.......................................... 36 8.2.4 Synapse............................................ 37 8.2.5 Open-Synapse Client..................................... 38 8.2.6 myTransport Gui....................................... 39 8.2.7 CarPal: a P2P carpooling service ............................. 39 8.2.8 Husky interpreter....................................... 408.3 Potential software .......................................... 41 8.3.1 myMed (in french), see http://www-sop.inria.fr/mymed . . . . . . . . . . . . . . . . 419 Contracts...........................................439.1 INTERREG Alcotra: myMed,2010-2013.............................. 43 9.2 COLOR:JMED,2010 ........................................ 43 9.3 FP6 FET GlobalComputing: IST AEOLUS, 2006-2010 ..................... 43 9.4 JET TEMPUS DEUKS, 2007-2009................................. 4410 Collaborations ...........................................4411 Self assessment ...........................................4411.1 Trivia ................................................. 45 11.2 Conclusions.............................................. 45We propose foundations for generic overlay networks and overlay computing systems. Such overlays are built over a large number of distributed computational agents, virtually organized in colonies or virtual organizations, and ruled by a leader (broker) who is elected democratically (vox populi, vox dei) or imposed by system administrators (primus inter pares). Every agent asks the broker to log in the colony by declaring the resources that can be offered (with variable guarantees). Once logged in, an agent can ask the broker for other resources. Colonies can recursively be considered as evolved agents who can log in an outermost colony governed by another super-leader. Communications and routing intra-colonies goes through a broker-2-broker PKI-based negotiation. Every broker routes intra- and inter- service requests by filtering its resource routing table, and then forwarding the request first inside its colony, and second outside, via the proper super-leader (thus applying an endogenous-first-estrogen- last strategy). Theoretically, queries are formulæ in first-order logic equipped with a small program used to orchestrate and synchronize atomic formulæ (atomic services). When the client agent receives notification of all (or part of) the requested resources, then the real resource exchange is performed directly by the server(s) agents, without any further mediation of the broker, in a pure peer-to-peer fashion. The proposed overlay promotes an intermittent participation in the colony, since peers can appear, disappear, and organize themselves dynamically. This implies that the routing process may lead to failures, because some agents have quit or are temporarily unavailable, or they were logged out manu militari by the broker due to their poor performance or greediness. We aim to design, validate through simulation, and implement these foundations in an overlay network computer system. (From [Liquori-Cosnard TGC-07 paper])

Peter, le langage qui n’existe pas...

“Inside every large language is a small language struggling to get out ...” [Igarashi et al. 2001]“... and inside every small language is a sharp extension looking for better expressivity ...” [Liquori & Spiwack 2008]It is my privilege and pleasure to introduce Peter, the language that does not exist... The Peter language contains almost the linguistic features I have introduced and investigated in the field of functional and object-oriented programming, plus some new features not published yet. In Peter’s Habilitation, I will try to limit as much as possible the mathematical overhead and the technicalities (e.g. full set of rules, full proofs of theorems, etc.). In my opinion, the habilitation thesis should not be a mere translation of the candidate’s most successful papers (3), nor a commented curriculum vitæ, nor a survey of all the related works in his scientific area (4), just to mention a few “classic Habilitation styles”. It is my opinion that it should be short in length since it is experienced that a very few Habilitation thesis are really downloaded, cited and read. Oftenly, habilitation thesis are not even made accessible on the Web. Peter’s Habilitation will be based on the following three points: • (Modularity) I will present a (Turing complete) kernel of Peter, called Baby Peter, and I will continue in the rest of the Habilitation to extend it in a modular fashion until the final extension, called Wise Peter. Baby Peter is a functional language with object-oriented features equipped with a sound type system. Peter bears some similarities to Atsushi, Benjamin and Phil’s Featherweight Java [IPW01] and Alonso Church’s typed lambda calculus [Chu41]. The main difference lies in an ad hoc exception-handling mechanism allowing the programmer to choose the type system according to her/his necessities and goals. Even more, it allows the programmer to write her/his own type system (see item (Type-programmable)). Some chapters will focus on operational semantics, some others on type systems, some others on both. All topics will be treated in a “lightweight fashion”. Examples of extensions are for instance mixing class-based and pure object-based features, but also improving proof languages à la LF with pattern matching facilities and including those metalanguages to Peter in order to mix algorithms and their correctness proofs. • (Verbatim-like) Instead of annoying the reader with a plain French translation of some of my most relevant papers (6), I will show, for each extension, only some key rules of the operational semantics or of the type system (every system has at least a key rule...) and some motivating examples. I do not plan to prove type soundness for each extension of Peter: the whole soundness of Wise Peter is left as a challenge for the “next” user friendly proof assistant.• (Type-programmable) Type systems for programming languages and proof languages are fixed a priori by language designers; type systems are not first class citizens. To my little knowledge, no language allows the programmer to build, choose, or mix type systems. The idea of modifying the type discipline at compile time is not completely new; a quite inspiring work has been done by the “visionary-6-pages” paper by Gilad in 2004 [Bra04] called Pluggable Type Systems. The possibility to mixing type systems and using it as a first class citizens is an interesting research strand that will constitute an original contribution in Peter’s Habilitation. With the intention of disseminating science in a simple, clear and pedagogical way, and inspired by the works of Kim [Bru99, TKB01, BDKT03, RBC+ 05, Bru02] and Gilles [Dow03, Dow07], I wish you a very nice reading of the Peter’s Habilitation. 3 Although certain parts are taken of my articles. 4 The typographic convention is that references to my papers are in “numeric” style while references to other papers are in “alphanumeric” style. 6 We provide a CD and a Web site with all my papers.C’est mon privilege et plaisir d’introduire Peter, le langage qui n’existe pas... Le langage Peter contient quasiment tous les aspects linguistiques que j’ai introduits et étudiés dans le domaine de la programmation fonctionnelle et objets, ainsi que quelques idées qui n’ont pas encore été publiées. Dans l’habilitation de Peter, la démarche que je suivrai consiste à essayer de limiter les détails concernant les aspects théoriques et techniques (c-à-d. les ensembles complets des règles de typage, suites de théorèmes abscons, etc.). Mon mémoire d’habilitation ne sera pas une traduction brutale des différents articles publiés (1), ni un curriculum vitæ commenté, ni un panorama de tous les articles dans un domaine scientifique (2), pour ne citer que quelques styles classiques de thèses d’habilitation. Tout d’abord elle sera courte car l’expérience enseigne que très peu de thèses d’habilitation sont réellement téléchargées, citées et lues. Très souvent, les thèses d’habilitation ne sont même pas accessibles sur le Web. L’Habilitation de Peter sera fondée sur les trois « dogmes » suivants: • (Modularité) Je commencerai par le plus petit fragment complet (au sens de Turing) de Peter, appelée Baby Peter et je continuerai de façon modulaire, d’extension en extension, jusqu’à l’extension finale appelée Sage Peter. Baby Peter est un langage fonctionnel avec des constructions linguistiques orientées objet et un système de types correct. Peter partage quelques similitudes avec Featherweight Java de Atsushi, Benjamin et Phil [IPW01] et le lambda calcul typé de Alonso (Church) [Chu41]. La différence principale entre Featherweight Java et Peter, est un mécanisme d’exceptions ad hoc, qui permet au programmeur de décider quel système de types sera le plus adapté à l’egard de ses nécessités et objectifs. En plus, ce mécanisme permet au programmeur d'écrire son système de types (voir point Type-programmable). Certains chapitres seront focalisés sur un nouveau système de types, tandis que, dans d’autres chapitres, l’extension sera associée à une extension de la syntaxe et du système de types. Tous les arguments seront traités d’une façon accessible au plus grand nombre de lecteurs. Comme exemples d’extensions, je citerai une forme nouvelle d'héritage multiple, une extension de Peter qui permettra à un objet de « s'échapper de sa classe », une extension de Peter avec filtrage évolué et enfin une extension de Peter qui permettra de mélanger algorithmes et preuves de correction d’algorithmes.• (Verbatim-like) Plutôt que d'asséner à mes lecteurs une traduction française mot-à-mot de mes articles scientifiques (5), j’ai privilegié une présentation simple de chaque extension, utilisant uniquement quelques règles clés de la sémantique opérationnelle ou du système de types (il y a toujours une règle clé...), en ajoutant immédiatement des exemples pour motiver et comprendre son utilisation correcte. Je ne prouverai pas la propriété de complétude de chaque système de types qui étend Peter : la complétude de Sage Peter est proposée en défi au prochain assistant à la preuve convivial. • (Type-programmable) Les systèmes de types pour les langages de programmation et pour la preuve sont fixés a priori par leurs concepteurs et ne sont pas des objets de première classe pouvant être modifiés ou simplement utilisés par le programmeur qui en subit les qualités et les faiblesses. À ma connaissance, aucun langage ne permet au programmeur de « programmer » sa discipline de types personnelle. L’idée de modifier la discipline de typage à la compilation n’est pas très nouvelle ; un article « visionnaire » de 6 pages, qui m'a eclairé, a été Pluggable Type System de Gilad [Bra04] sorti en 2004. La possibilité de permettre au programmeur d'écrire sa propre discipline de typage et de l’utiliser à la volée est par elle-même une contribution originale dans l’habilitation de Peter. Avec l’envie de diffuser la connaissance scientifique de façon simple, claire et pédagogique, inspiré par les ouvrages de Kim [Bru99,TKB01, BDKT03, RBC+ 05, Bru02] et Gilles [Dow03, Dow07], il ne me reste plus qu'à vous souhaiter une bonne lecture de l’habilitation de Peter. 1. Bien que certaines parties soient tirées de mes articles. 2. La convention typographique est que les référence à mes articles soit en style « numérique » tandis que les références à d’autres articles soit en « alphanumérique ». 5 Un CD et un site web contiendront tous mes articles. <br

The Effect Use of Different Binding Materials on Water Holding Capacity, Water Content and Crude Fiber Content of Chicken Nuggets

This study aims to determine the water holding capacity, moisture content and crude fiber content of chicken nuggets made using different types of flour as a binder. This research was conducted at the Laboratory of the Faculty of Animal Husbandry, Nusa Cendana University, Kupang for 1 week. The method used in this study was a completely randomized design (CRD) with 3 treatments and 3 replications. The treatments were P1 (making nuggets with porang flour), P2 (making nuggets with tapioca flour), and P3 (making nuggets with wheat flour). The variables observed in this study included water holding capacity, water content and crude fiber content. The data obtained were analyzed using the Anova test and Duncan's test. The results of the study showed that the water holding capacity of chicken nuggets P1, P2, P3 were 36.956%, 34.621%, 32.756%, respectively. The water content of chicken nuggets was 64.17%, 59.95%, 57.71%, respectively. The crude fiber content of chicken nuggets is 1.387%, 1.169%, and 0.638% respectively. The statistical analysis showed that the treatment had a significant effect on the water holding capacity of chicken nuggets, water content of chicken nuggets and crude fiber content of chicken nuggets (P&lt;0.05). It was concluded that the water content of chicken nuggets made from wheat flour and tapioca was in accordance with SNI, while the production of nuggets made from porang flour exceeded the Indonesian National Standard, but porang flour had the advantage of being able to bind water better

An Open Logical Framework

The LFP Framework is an extension of the Harper-Honsell-Plotkin's Edinburgh Logical Framework LF with external predicates, hence the name Open Logical Framework. This is accomplished by defining lock type constructors, which are a sort of \u25a1-modality constructors, releasing their argument under the condition that a possibly external predicate is satisfied on an appropriate typed judgement. Lock types are defined using the standard pattern of constructive type theory, i.e. via introduction, elimination and equality rules. Using LFP, one can factor out the complexity of encoding specific features of logical systems, which would otherwise be awkwardly encoded in LF, e.g. side-conditions in the application of rules in Modal Logics, and sub-structural rules, as in non-commutative Linear Logic. The idea of LFP is that these conditions need only to be specified, while their verification can be delegated to an external proof engine, in the style of the Poincar Principle or Deduction Modulo. Indeed such paradigms can be adequately formalized in LFP. We investigate and characterize the meta-theoretical properties of the calculus underpinning LFP: strong normalization, confluence and subject reduction. This latter property holds under the assumption that the predicates are well-behaved, i.e. closed under weakening, permutation, substitution and reduction in the arguments. Moreover, we provide a canonical presentation of LFP, based on a suitable extension of the notion of \u3b2\u3b7-long normal form, allowing for smooth formulations of adequacy statements. \ua9 The Author, 2013

LogNet: Extending Internet with a Network Aware Discovery Service: [Extended abstract]

[Everything needs to change, so everything can stay the same, From “The Leopard” by Giuseppe Tomasi di Lampedusa] Internet in recent years has become a huge set of channels for content distribution. And this has highlighted limits and inefficiencies of the current protocol suite originally designed for host-to-host communication. This paper joins the research efforts addressed by the new Internet challenges by proposing LogNet, a conservative extension of the current TCP/IP hourglass Internet architecture, that provides a new network aware Content Discovery Service.Contents are referred via the new notion of HyperNames (HN), whose rich syntax allow to specify, hosts, pki, fingerprint and a large list of optional logical attributes (tags) attached to the content name, such as mutable vs immutable contents, digital signatures, ownership, availability, price, etc. HyperNames are in part human-readable and in part machine-readable and only in the latter case self-certifying.Publication and discovery of HN is achieved using the new distributed service Content Name System (CNS) with related protocol, whose behavior and architecture is, partly, inspired by the DNS, and whose “routing logic” uses the BGP inter domain routing information.The core of CNS is the HyperName Lookup Algorithm (HLA) which “tunes” content discovery of being network aware, by exploiting the Autonomous System (AS) relationships. In partic- ular, the HLA starts the content discovery process in the local AS (i.e., where the query starts), and in case of negative answer, propagate the query by accounting for the AS-to-AS relationships (i.e., peering, provider-to-customer, customer-to-provider). After discovered the owner(s) or the purveyor(s) of the content we are looking for, the latter can be retrieved using common transfer protocols (centralized or distributed), since the actors of this transfer are chosen in a network aware fashion (i.e., as close as possible one to each other)

Extending FeatherTrait Java with Interfaces

International audienceIn the context of Featherweight Java by Igarashi, Pierce, and Wadler, and its recent extension FeatherTrait Java (FTJ) by the authors, we investigate classes that can be extended with trait composition. A trait is a collection of methods, i.e. behaviors without state; it can be viewed as an "incomplete stateless class" ie, an interface with some already written behavior. Traits can be composed in any order, but only make sense when "imported" by a class that provides state variables and additional methods to disambiguate conflicting names arising between the imported traits. We introduce FeatherTrait Java with interfaces (iFTJ), where traits need to be typechecked only once, which is necessary for compiling them in isolation, and considering them as regular types, like Java-interfaces with a behavioral content