I/O trees and interactive lazy functional programming

Author(s):  
Samuel A. Rebelsky
1995 ◽  
Vol 5 (3) ◽  
pp. 317-343 ◽  
Author(s):  
Donald A Ziff ◽  
Stephen P Spackman ◽  
Keith Waclena

AbstractThis paper describes a data-intensive application written in a lazy functional language: a server for textual information retrieval. The design illustrates the importance of interoperability, the capability of interacting with code written in other programming languages. Lazy functional programming is shown to be a powerful and elegant means of accomplishing several desirable concrete goals: delivering initial results promptly, using space economically, and avoiding unnecessary I/O. Performance results, however, are mixed.


2006 ◽  
Vol 41 (3) ◽  
pp. 30-39 ◽  
Author(s):  
Anthony H. Dekker

2002 ◽  
Vol 12 (4-5) ◽  
pp. 293-294
Author(s):  
GRAHAM HUTTON

Since its inception in 1987, Haskell has provided a focal point for research in lazy functional programming. During this time the language has continually evolved, as a result of both theoretical advances and practical experience. Haskell has proved to be a powerful tool for many kinds of programming tasks, and an excellent vehicle for many aspects of computing pedagogy and research. The recent definition of Haskell 98 provides a long-awaited stable version of the language, but there are many exciting possibilities for future versions of Haskell.


1993 ◽  
Vol 3 (2) ◽  
pp. 171-190 ◽  
Author(s):  
F. Warren Burton ◽  
Robert D Cameron

AbstractPattern matching in modern functional programming languages is tied to the representation of data. Unfortunately, this is incompatible with the philosophy of abstract data types.Two proposals have been made to generalize pattern matching to a broader class of types. The laws mechanism of Miranda allows pattern matching with non-free algebraic data types. More recently, Wadler proposed the concept of views as a more general solution, making it possible to define arbitrary mappings between a physical implementation and a view supporting pattern matching. Originally, it was intended to include views in the new standard lazy functional programming language Haskell.Laws and views each offer important advantages, particularly with respect to data abstraction. However, if not used with great care, they also introduce serious problems in equational reasoning. As a result, laws have been removed from Miranda and views were not included in the final version of Haskell.We propose a third approach which unifies the laws and views mechanisms while avoiding their problems. Philosophically, we view pattern matching as a bundling of case recognition and component selection functions instead of a method for inverting data construction. This can be achieved by removing the implied equivalence between data constructors and pattern constructors. In practice, we allow automatic mapping into a view but not out of the view. We show that equational reasoning can still be used with the resulting system. In fact, equational reasoning is easier, since there are fewer hidden traps.


Sign in / Sign up

Export Citation Format

Share Document