The RelView-System is an interactive tool for computer-supported manipulation of relations represented as Boolean matrices or directed graphs, especially for prototyping relational specifications and programs.. Examples for RelView programs: o Approximation algorithms o Graph-theoretic algorithms o Algorithms for orders and lattices o Algorithms for C/E Petri nets o Recursive programs o Miscellaneous The KURE for your relational problems - The Kiel University Relation package contains the relational functions of RelView in an easy to use linkable C library. The Java library KURE-Java is an extension of the KURE library and has been developed at the Chair of Software Technology at the University of Dortmund. Currently this Java library is used to reimplement RelView as plugin for the development platform Eclipse, called RelClipse .
The COST Action 274 TARSKI Web Portal for Relation Software as of May 15, 2005 When an engineer is about to design an artefact and has to apply Linear Algebra methods (such as solving systems of linear equations or determining eigenvalues and eigenvectors), he will approach the respective computing center and most certainly get the necessary software. When the matrices considered become boolean matrices, i.e., relations, the situation changes dramatically. Neither will one find persons competent in that, nor will there exist commonly accepted high-quality software. Even formulation of the ideas is often bound to the respective scientists personal habits of denotation. This situation is addressed by the present attempt for a common web portal for relation software.
A compiled, type-safe, multi-stage programming language. MetaOCaml is a multi-stage extension of the OCaml programming language, and provides three basic constructs called Brackets, Escape, and Run for building, combining, and executing future-stage computations, respectively. (Please read README-META file in distribution for MetaOCaml's syntax for these constructs). MetaOCaml is a compiled dialect of MetaML. Download current (February 3nd, 2006) (or archived distributions) and follow instructions in INSTALL-META. For Windows, you'll need Cygwin Hot from the Press!: Science of Computer Programming special issue on MetaOCaml Learn more about multi-stage programming.
ML modules provide hierarchical namespace management, as well as fine-grained control over the propagation of type information, but they do not allow modules to be broken up into separately compilable, mutually recursive components. Mixin modules facilitate recursive linking of separately compiled components, but they are not hierarchically composable and typically do not support type abstraction. We synthesize the complementary advantages of these two mechanisms in MixML. A MixML module is like an ML structure with some components specified but not defined unifing the ML structure and signature languages into one. MixML seamlessly integrates hierarchical composition, translucent MLstyle data abstraction, and mixin-style recursive linking.Tthe design of MixML is minimalist emphasizing how all the interesting features of the ML module system can be understood simply as stylized uses of a small set of orthogonal underlying constructs, with mixin composition playing a central role.
Datatype-Generic Programming Roland Backhouse at the University of Nottingham and Jeremy Gibbons at the University of Oxford have a joint EPSRC-supported project entitled Datatype-Generic Programming, running for three years and starting on 1st October 2003. Aim The project is to develop a novel mechanism for parametrizing programs, namely parametrization by a datatype or type constructor. The mechanism is related to parametric polymorphism, but of higher order. We aim to develop a calculus for constructing datatype-generic programs, with the ultimate goal of improving the state of the art in generic object-oriented programming, as occurs for example in the C++ Standard Template Library. further details of the project can be obtained from the contacts listed below.
The problem we're trying to solve is to get a game object from the starting point to a goal. Pathfinding addresses the problem of finding a good path from the starting point to the goal―avoiding obstacles, avoiding enemies, and minimizing costs (fuel, time, distance, equipment, money, etc.). Movement addresses the problem of taking a path and moving along it. It's possible to spend your efforts on only one of these. At one extreme, a sophisticated pathfinder coupled with a trivial movement algorithm would find a path when the object begins to move and the object would follow that path, oblivious to everything else. At the other extreme, a movement-only system would not look ahead to find a path (instead, the initial "path" would be a straight line), but instead take one step at a time, considering the local environment at every point. Best results are achieved by using both pathfinding and movement algorithms.
As part of a larger project, we have built a declarative assembly language. This language enables us to specify multiple code paths to compute particular quantities, giving the instruction scheduler more flexibility in balancing execution resources for superscalar execution. The instruction scheduler is also innovative in that it includes aggressive pipelining, and exhaustive (but lazy) search for optimal instruction schedules. We present some examples where our approach has produced very promising results. I think this paper is a nice followup to the recent discussion of SPE because it goes further than that paper by analyzing what data are necessary to achieve the ultimate goal of optimal or near-optimal instruction scheduling on superscalar architectures. In other words, it strongly suggests that we can do better than simply embedding low-level instructions in a high-level language by instead embedding a graph of desired results (vertices) and instructions for reaching them
One of the key goals of rewriting logic from its beginning has been to provide a semantic and logical framework in which many models of computation and languages can be naturally represented. There is by now very extensive evidence supporting the claim that rewriting logic is indeed a very flexible and simple logical and semantic framework. From a language design point of view the obvious question to ask is: how can a rewriting logic language best support logical and semantic framework applications, so that it becomes a metalanguage in which a very wide variety of logics and languages can be both semantically defined, and implemented? Our answer is: by being reflective. This paper discusses our latest language design and implementation work on Maude as a reflective metalanguage in which entire environments---including syntax definition, parsing, pretty printing, execution, and input/output---can be defined for a language or logic L of choice.
Stratego/XT is a language and toolset for constructing stand-alone program transformation systems. It combines the Stratego transformation language with the XT toolset of transformation components, providing a framework for constructing stand-alone program transformation systems. The Stratego language is based around a programming paradigm called strategic term rewriting. It provides rewrite rules for expressing basic transformation steps. The application of these rules can be controlled using strategies, a form of subroutines. The XT toolset provides reusable transformation components and declarative languages for deriving new components. Program transformations often operate by modifying the (AST). In Stratego it is also possible to specify transformations using concrete syntax. This allows programmers to express a transformation using the familiar (and often more concise) syntax of the object programming language, while it internally still operates on the AST.
I'm interested in the relative merits of ATS vs. Epigram which is a Pure Type System that seeks to unify types and terms, where ATS distinguishes the statics and dynamics of the language. What benefits and limitations do these approaches have on complexity for both developer and implementor? notes in atsVepig.txt