577 research outputs found

    Tracing and Debugging of Lazy Functional Programs - A Comparative Evaluation of Three Systems

    Get PDF
    In this paper we compare three systems for tracing and debugging Haskell programs: Freja, the Redex Trail System and Hood. We identify the similarities and differences of these systems and we evaluate their usefulness in practice by applying them to a number of small to medium programs in which errors had deliberately been introduced

    Structure and Properties of Traces for Functional Programs

    Get PDF
    The tracer Hat records in a detailed trace the computation of a program written in the lazy functional language Haskell. The trace can then be viewed in various ways to support program comprehension and debugging. The trace was named the augmented redex trail. Its structure was inspired by standard graph rewriting implementations of functional languages. Here we describe a model of the trace that captures its essential properties and allows formal reasoning. The trace is a graph constructed by graph rewriting but goes beyond simple term graphs. Although the trace is a graph whose structure is independent of any rewriting strategy, we define the trace inductively, thus giving us a powerful method for proving its properties

    Type Generic Observing

    Get PDF
    Observing intermediate values helps to understand what is going on when your program runs. Gill presented an observation method for lazy functional languages that preserves the program's semantics. However, users need to define for each type how its values are observed: a laborious task and strictness of the program can easily be affected. Here we define how any value can be observed based on the structure of its type by applying generic programming frameworks. Furthermore we present an extension to specify per observation point how much to observe of a value. We discuss especially functional values and behaviour based on class membership in generic programming frameworks

    Applying Formal Methods to Networking: Theory, Techniques and Applications

    Full text link
    Despite its great importance, modern network infrastructure is remarkable for the lack of rigor in its engineering. The Internet which began as a research experiment was never designed to handle the users and applications it hosts today. The lack of formalization of the Internet architecture meant limited abstractions and modularity, especially for the control and management planes, thus requiring for every new need a new protocol built from scratch. This led to an unwieldy ossified Internet architecture resistant to any attempts at formal verification, and an Internet culture where expediency and pragmatism are favored over formal correctness. Fortunately, recent work in the space of clean slate Internet design---especially, the software defined networking (SDN) paradigm---offers the Internet community another chance to develop the right kind of architecture and abstractions. This has also led to a great resurgence in interest of applying formal methods to specification, verification, and synthesis of networking protocols and applications. In this paper, we present a self-contained tutorial of the formidable amount of work that has been done in formal methods, and present a survey of its applications to networking.Comment: 30 pages, submitted to IEEE Communications Surveys and Tutorial

    Model Transformations in MT

    Get PDF
    Model transformations are recognised as a vital aspect of Model Driven Development,but current approaches cover only a small part of the possible spectrum. In this paper I present the MT model transformation which shows how a QVT-like language can be extended with novel pattern matching constructs, how tracing information can be automatically constructed and visualized, and how the transformed model is pruned of extraneous elements. As MT is implemented as a DSL within the Converge language, this paper also demonstrates how a general purpose language can be embedded in a model transformation language, and how DSL development can aid experimentation and exploration of new parts of the model transformation spectrum

    Logic programming in the context of multiparadigm programming: the Oz experience

    Full text link
    Oz is a multiparadigm language that supports logic programming as one of its major paradigms. A multiparadigm language is designed to support different programming paradigms (logic, functional, constraint, object-oriented, sequential, concurrent, etc.) with equal ease. This article has two goals: to give a tutorial of logic programming in Oz and to show how logic programming fits naturally into the wider context of multiparadigm programming. Our experience shows that there are two classes of problems, which we call algorithmic and search problems, for which logic programming can help formulate practical solutions. Algorithmic problems have known efficient algorithms. Search problems do not have known efficient algorithms but can be solved with search. The Oz support for logic programming targets these two problem classes specifically, using the concepts needed for each. This is in contrast to the Prolog approach, which targets both classes with one set of concepts, which results in less than optimal support for each class. To explain the essential difference between algorithmic and search programs, we define the Oz execution model. This model subsumes both concurrent logic programming (committed-choice-style) and search-based logic programming (Prolog-style). Instead of Horn clause syntax, Oz has a simple, fully compositional, higher-order syntax that accommodates the abilities of the language. We conclude with lessons learned from this work, a brief history of Oz, and many entry points into the Oz literature.Comment: 48 pages, to appear in the journal "Theory and Practice of Logic Programming

    Compositional explanation of types and algorithmic debugging of type errors

    Get PDF

    Future of Functional Reactive Programming in Real-Time Systems

    Get PDF
    The evolution of programming paradigms and the development of new programming languages are driven by the needs of problem domains. Functional reactive programming (FRP) combines functional programming (FP) and reactive programming (RP) concepts that leverage asynchronous dataflow from reactive programming and higher-level abstractions building blocks from functional programming to enable developers to define data flows and transformations declaratively. Declarative programming allows developers to concentrate more on the problem to be solved rather than the implementation details, resulting in efficient and concise code. Over the years, various FRP designs have been proposed in real-time application areas. Still, it remains unclear how FRP-based solutions compare with traditional methods for implementing these applications. In this survey, we studied the usefulness of FRP in some real-time applications, such as game development, animation, graphical user interface(GUI), and embedded system. We conducted a qualitative comparison for game development and studied various applications in animation, GUI, and embedded systems. We found that using FRP in these applications is quite difficult because of insufficient libraries and tools. Additionally, due to high learning curves and a need for experienced developers, the development process in FRP takes time and effort. Our examination of two well-known games: Asteroid and Pong, in three programming paradigms: imperative programming using the Unity game engine, FP in Haskell, and FRP in the Yampa library, showed that imperative programming is effective in terms of performance and usability. The other two paradigms for developing games from scratch are inefficient and challenging. Despite the fact that FRP was designed for animation, the majority of its applications are underperforming. FRP is more successful for GUI applications, where libraries like RxJS have been used in many web interfaces. FRP is also applied in developing embedded system applications for its effective memory management, maintainability, and predictability. Developing efficient solutions from scratch is not suitable in FRP due to several factors, such as poor performance compared to other programming paradigms, programming complexity, and a steep learning curve. Instead, developers can be benefited from utilizing FRP-supported modular platforms to build robust and scalable real-time applications
    corecore