Implicit complexity for coinductive data: a characterization of corecurrence

We propose a framework for reasoning about programs that manipulate coinductive data as well as inductive data. Our approach is based on using equational programs, which support a seamless combination of computation and reasoning, and using productivity (fairness) as the fundamental assertion, rather than bi-simulation. The latter is expressible in terms of the former. As an application to this framework, we give an implicit characterization of corecurrence: a function is definable using corecurrence iff its productivity is provable using coinduction for formulas in which data-predicates do not occur negatively. This is an analog, albeit in weaker form, of a characterization of recurrence (i.e. primitive recursion) in [Leivant, Unipolar induction, TCS 318, 2004].Comment: In Proceedings DICE 2011, arXiv:1201.034

A principled approach to REPL interpreters

Read-eval-print-loops (REPLs) allow programmers to test out snippets of code, explore APIs, or even incrementally construct code, and get immediate feedback on their actions. However, even though many languages provide a REPL, the relation between the language as is and what is accepted at the REPL prompt is not always well-defined. Furthermore, implementing a REPL for new languages, such as DSLs, may incur significant language engineering cost. In this paper we survey the domain of REPLs and investigate the (formal) principles underlying REPLs. We identify and define the class of sequential languages, which admit a sound REPL implementation based on a definitional interpreter, and present design guidelines for extending existing language implementations to support REPL-style interfaces (including computational notebooks). The obtained REPLs can then be generically turned into an exploring interpreter, to allow exploration of the user’s interaction.The approach is illustrated using three case studies, based on MiniJava, QL (a DSL for questionnaires), and eFLINT (a DSL for normative rules). We expect sequential languages, and the consequent design principles, to be stepping stones towards a better understanding of the essence of REPLs.</p

Entities for CFI: CFI Language Design Study Notes

implementation. Sy4) Abstract program A definition of an &quot;executable&quot; formal structure. Possible meanings for &quot;executable formal structure&quot; are: -- is computable, -- can be interpreted (all parts of the formal structure may be executed), -- can be prototyped/animated (some parts of the formal structure may be executed), -- can be compiled into some &quot;programming language&quot;. Other suggestions for the name: Abstract implementation. Sy5) Program It is intended as a program in some programming language. Here &quot;programming language&quot; should be intended &quot;truly commonly used/commercially available programming language&quot;; thus a programming language equipped with static, dynamic semantics, a &quot;professional&quot; environment (checker of the static correctness, interpreter and/or compiler), non-academic applications, tested/ used along a consistent time. It may be that the programming language is not based on the same features on which are based the formal structures and the related specifications (e.g...

Towards a Well-Founded UML-based Development Method

This paper presents an attempt, perhaps unorthodox, at bridging the gap between the use of formal techniques and the current software engineering practices. After years of full immersion in the development and use of formal techniques, we have been led to suggest a Virtuous Cycle philosophy, better marrying the rigour of formalities to the needs and, why not, the wisdom of current practices. What we have called Well-Founded Software Development Methods is a strategy compliant with that philosophy, that essentially aims at proposing methods where the formalities provide the foundational rigour, and perhaps may inspire new techniques, but are kept hidden from the user

A Discipline for Handling Feature Interaction

. A challenging problem within the wider software evolution problem is the development of systems by features. While most of the recent work centered around the detection of feature interactions, we present an approach based on modular specification, separation of concerns and prevention of unwanted interactions. We illustrate our approach extending a formalism for the specification of reactive systems and showing its application to some aspects of the well-known case of telephone systems (POTS and variations). The paper concentrates more on the methodological aspects, which are, at large extent, independent of the formalism. Indeed, this seems to be the case of some rather novel concepts like the distinction between prefeatures (features in isolation) and features, closed and open semantics, feature composition and discipline of feature interaction, and finally the pervading role of a kind of anti-frame assumption. Introduction Evolution in software development has many facets. One w..

Relationships between Logical Frames

none2Selected Papers from the 8th Workshop on Specification of Abstract Data Types Joint with the 3rd COMPASS WorkshopE. ASTESIANO; M. CERIOLIAstesiano, Egidio; Cerioli, Maur

Big-Data/Analytics Projects Failure: A Literature Review

Nowadays, no one doubt that big data and analytics are fundamental tools for successfully running an enterprise. However, big data/analytics projects do not seem to be all sunshine and rainbows, and this is documented by many sources providing startling figures of failed projects. Motivated by such figures, we conducted a (grey and scientific) literature review aimed to answer: RQ1) Which are the documented cases of failed BD/A projects, and which are the root causes of their failures? RQ2) What is assumed useful to reduce the chance of failure of BD/A projects? We collected and examined 188 sources. The survey resulted first in a list of hints for helping avoid the failure of the BD/A projects (RQ2), and in a list of 21 cases of failed BD/A projects documented in the literature (RQ1). The analysis of those failures resulted in confirming the hints of RQ2 and prompting other relevant ones. The result of this study will be useful not only to people developing a BDA project but also to researchers investigating the challenges proposed by a BDA project to the traditional methods of software engineering

Algebraic specification of concurrency

none2E. Astesiano;G. ReggioAstesiano, Egidio; Reggio, Giann

Formalism and Method

ion level of specifications Once we have given the formal models, we can qualify the abstraction degree of the specification language in the sense how much abstract its specifications can be, and so providing some information about at which points in the development process it may be used. The abstraction degree is related to the cardinality of the classes of formal models that are semantics of the specifications. The less abstract specification methods are those where [[SP]] has cardinality 1 or is just an isomorphism class. 2.6.2 Specification semantics The technique used for providing the semantics of specification language is not neutral; indeed such semantics can be given in -- A rather direct, explicit and denotational way (e.g., as done by Hoare for CSP, [19]), by exhibiting the relative class of formal models -- An indirect or implicit way, say as (1) the limit of a diagram in a category, (2) defining that two specifications are semantically equivalent iff their equality ..