scholarly journals Editorial - Lazy Functional Programming

1989 ◽  
Vol 32 (2) ◽  
pp. 97-97 ◽  
Author(s):  
P. Wadler
Keyword(s):  
Functional Programming ◽  
Lazy Functional Programming

Funser: a functional server for textual information retrieval

1995 ◽  
Vol 5 (3) ◽  
pp. 317-343 ◽  
Author(s):  
Donald A Ziff ◽  
Stephen P Spackman ◽  
Keith Waclena
Keyword(s):  
Information Retrieval ◽  
Programming Languages ◽  
Functional Programming ◽  
Functional Language ◽  
Textual Information ◽  
Data Intensive ◽  
Performance Results ◽  
Lazy Functional Programming ◽  
Initial Results ◽  
Data Intensive Application

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.

Lazy functional programming in Java

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

scholarly journals Special Double Issue on Haskell

2002 ◽  
Vol 12 (4-5) ◽  
pp. 293-294
Author(s):  
GRAHAM HUTTON
Keyword(s):  
Functional Programming ◽  
Focal Point ◽  
Practical Experience ◽  
Definition Of ◽  
Lazy Functional Programming

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.

Pattern matching with abstract data types

1993 ◽  
Vol 3 (2) ◽  
pp. 171-190 ◽  
Author(s):  
F. Warren Burton ◽  
Robert D Cameron
Keyword(s):  
Programming Languages ◽  
Pattern Matching ◽  
Functional Programming ◽  
Abstract Data Types ◽  
Data Types ◽  
Functional Programming Languages ◽  
Equational Reasoning ◽  
Abstract Data ◽  
Algebraic Data Types ◽  
Lazy Functional Programming

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