Abstract State Machines 1988-1998: Commented ASM Bibliography

An annotated bibliography of papers which deal with or use Abstract State Machines (ASMs), as of January 1998.Comment: Also maintained as a BibTeX file at http://www.eecs.umich.edu/gasm

Several types of types in programming languages

Types are an important part of any modern programming language, but we often forget that the concept of type we understand nowadays is not the same it was perceived in the sixties. Moreover, we conflate the concept of "type" in programming languages with the concept of the same name in mathematical logic, an identification that is only the result of the convergence of two different paths, which started apart with different aims. The paper will present several remarks (some historical, some of more conceptual character) on the subject, as a basis for a further investigation. The thesis we will argue is that there are three different characters at play in programming languages, all of them now called types: the technical concept used in language design to guide implementation; the general abstraction mechanism used as a modelling tool; the classifying tool inherited from mathematical logic. We will suggest three possible dates ad quem for their presence in the programming language literature, suggesting that the emergence of the concept of type in computer science is relatively independent from the logical tradition, until the Curry-Howard isomorphism will make an explicit bridge between them.Comment: History and Philosophy of Computing, HAPOC 2015. To appear in LNC

Solution Repair/Recovery in Uncertain Optimization Environment

Operation management problems (such as Production Planning and Scheduling) are represented and formulated as optimization models. The resolution of such optimization models leads to solutions which have to be operated in an organization. However, the conditions under which the optimal solution is obtained rarely correspond exactly to the conditions under which the solution will be operated in the organization.Therefore, in most practical contexts, the computed optimal solution is not anymore optimal under the conditions in which it is operated. Indeed, it can be "far from optimal" or even not feasible. For different reasons, we hadn't the possibility to completely re-optimize the existing solution or plan. As a consequence, it is necessary to look for "repair solutions", i.e., solutions that have a good behavior with respect to possible scenarios, or with respect to uncertainty of the parameters of the model. To tackle the problem, the computed solution should be such that it is possible to "repair" it through a local re-optimization guided by the user or through a limited change aiming at minimizing the impact of taking into consideration the scenarios