38,250 research outputs found
Liveness-Based Garbage Collection for Lazy Languages
We consider the problem of reducing the memory required to run lazy
first-order functional programs. Our approach is to analyze programs for
liveness of heap-allocated data. The result of the analysis is used to preserve
only live data---a subset of reachable data---during garbage collection. The
result is an increase in the garbage reclaimed and a reduction in the peak
memory requirement of programs. While this technique has already been shown to
yield benefits for eager first-order languages, the lack of a statically
determinable execution order and the presence of closures pose new challenges
for lazy languages. These require changes both in the liveness analysis itself
and in the design of the garbage collector.
To show the effectiveness of our method, we implemented a copying collector
that uses the results of the liveness analysis to preserve live objects, both
evaluated (i.e., in WHNF) and closures. Our experiments confirm that for
programs running with a liveness-based garbage collector, there is a
significant decrease in peak memory requirements. In addition, a sizable
reduction in the number of collections ensures that in spite of using a more
complex garbage collector, the execution times of programs running with
liveness and reachability-based collectors remain comparable
Fine-grained visualization pipelines and lazy functional languages
The pipeline model in visualization has evolved from a conceptual model of data processing into a widely used architecture for implementing visualization systems. In the process, a number of capabilities have been introduced, including streaming of data in chunks, distributed pipelines, and demand-driven processing. Visualization systems have invariably built on stateful programming technologies, and these capabilities have had to be implemented explicitly within the lower layers of a complex hierarchy of services. The good news for developers is that applications built on top of this hierarchy can access these capabilities without concern for how they are implemented. The bad news is that by freezing capabilities into low-level services expressive power and flexibility is lost. In this paper we express visualization systems in a programming language that more naturally supports this kind of processing model. Lazy functional languages support fine-grained demand-driven processing, a natural form of streaming, and pipeline-like function composition for assembling applications. The technology thus appears well suited to visualization applications. Using surface extraction algorithms as illustrative examples, and the lazy functional language Haskell, we argue the benefits of clear and concise expression combined with fine-grained, demand-driven computation. Just as visualization provides insight into data, functional abstraction provides new insight into visualization
Combining Static and Dynamic Contract Checking for Curry
Static type systems are usually not sufficient to express all requirements on
function calls. Hence, contracts with pre- and postconditions can be used to
express more complex constraints on operations. Contracts can be checked at run
time to ensure that operations are only invoked with reasonable arguments and
return intended results. Although such dynamic contract checking provides more
reliable program execution, it requires execution time and could lead to
program crashes that might be detected with more advanced methods at compile
time. To improve this situation for declarative languages, we present an
approach to combine static and dynamic contract checking for the functional
logic language Curry. Based on a formal model of contract checking for
functional logic programming, we propose an automatic method to verify
contracts at compile time. If a contract is successfully verified, dynamic
checking of it can be omitted. This method decreases execution time without
degrading reliable program execution. In the best case, when all contracts are
statically verified, it provides trust in the software since crashes due to
contract violations cannot occur during program execution.Comment: Pre-proceedings paper presented at the 27th International Symposium
on Logic-Based Program Synthesis and Transformation (LOPSTR 2017), Namur,
Belgium, 10-12 October 2017 (arXiv:1708.07854
An Integrated Development Environment for Declarative Multi-Paradigm Programming
In this paper we present CIDER (Curry Integrated Development EnviRonment), an
analysis and programming environment for the declarative multi-paradigm
language Curry. CIDER is a graphical environment to support the development of
Curry programs by providing integrated tools for the analysis and visualization
of programs. CIDER is completely implemented in Curry using libraries for GUI
programming (based on Tcl/Tk) and meta-programming. An important aspect of our
environment is the possible adaptation of the development environment to other
declarative source languages (e.g., Prolog or Haskell) and the extensibility
w.r.t. new analysis methods. To support the latter feature, the lazy evaluation
strategy of the underlying implementation language Curry becomes quite useful.Comment: In A. Kusalik (ed), proceedings of the Eleventh International
Workshop on Logic Programming Environments (WLPE'01), December 1, 2001,
Paphos, Cyprus. cs.PL/011104
The Resource constrained shortest path problem implemented in a lazy functional language
The resource constrained shortest path problem is an NP-hard problem for which many ingenious algorithms have been developed. These algorithms are usually implemented in FORTRAN or another imperative programming language. We have implemented some of the simpler algorithms in a lazy functional language. Benefits accrue in the software engineering of the implementations. Our implementations have been applied to a standard benchmark of data files, which is available from the Operational Research Library of Imperial College, London. The performance of the lazy functional implementations, even with the comparatively simple algorithms that we have used, is competitive with a reference FORTRAN implementation
- …