Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Malcolm Wallace

dblp:00/4756 · DBLP profile ↗
← Back
6ranked-venue papers
3as first author
0since 2021 · last 2009
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 5 · 3 first-authorGraphics, computer vision, multimedia, augmented reality and games · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer graphics and multimedia
1 paper
Visualization and visual analytics · 100%
Software engineering, system software, and programming languages
1 paper
Programming languages and type systems · 100%

Topics — the 2 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Visualization and visual analytics › visualization theory
visualization pipeline
0.112006
Fine-grained Visualization Pipelines and Lazy Functional Languages · IEEE Trans. Vis. Comput. Graph. 2006
Programming languages and type systems › functional language
lazy functional languages
0.112006
Fine-grained Visualization Pipelines and Lazy Functional Languages · IEEE Trans. Vis. Comput. Graph. 2006

Methods — techniques the papers use, named apart from their topics

lazy evaluation · 0.1function composition · 0.1
YearPublicationVenuePosition
2009 Huge Data But Small Programs: Visualization Design via Multiple Embedded DSLs
David J. Duke, Rita Borgo, Malcolm Wallace, Colin Runciman
PADL3
2008 Experience report: visualizing data through functional pipelines
David J. Duke, Rita Borgo, Colin Runciman, Malcolm Wallace
ICFP4
2006 Fine-grained Visualization Pipelines and Lazy Functional Languages
abstract
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.
David J. Duke, Malcolm Wallace, Rita Borgo, Colin Runciman
IEEE Trans. Vis. Comput. Graph.2
1999 Haskell and XML: Generic Combinators or Type-Based Translation?
abstract
We present two complementary approaches to writing XML document-processing applications in a functional language.In the first approach, the generic tree structure of XML documents is used as the basis for the design of a library of combinators for generic processing: selection, generation, and transformation of XML trees.The second approach is to use a type-translation framework for treating XML document type definitions (DTDs) as declarations of algebraic data types, and a derivation of the corresponding functions for reading and writing documents as typed values in Haskell.
Malcolm Wallace, Colin Runciman
ICFP1
1998 The Bits Between The Lambdas: Binary Data in a Lazy Functional Language
abstract
For the programmer, storage media are usually assumed to have a minimum atomic unit of transfer of one byte. However, sometimes it is useful to have an even finer storage granularity of one bit, for instance in order to compress data.This paper describes an API in the lazy functional language Haskell for treating storage media as arbitrary-length streams of bits without byte-alignment constraints. So far as possible, storage media are treated uniformly. In particular, bit-stream memory and binary files share the same API -- a new and useful abstraction over memory management and file management. This uniformity of access leads to a novel technique for lazy random-access to files in a purely functional manner. We also describe a technique for automatically deriving compressed binary representations of user-defined data structures, whose operations provide both in-heap data compression and convenient high-level binary I/O.Of many possible applications, we illustrate the processing of Huffman-encoded image data, and a bibliographic information system which uses lazy B-trees for efficient storage management.
Malcolm Wallace, Colin Runciman
ISMM1
1995 Extending a Functional Programming System for Embedded Applications
abstract
Abstract Functional languages do not usually mesh well with embedded applications because of the need for special I/O device‐handling. By introducing a process model to a language, however, it becomes possible to express register‐level device operations and interrupts in a modular manner. This paper describes such a model, its implementation by extension to the Gofer programming system, and examples of its use. Performance results indicate that even this prototype interpretive system is adequate for small applications. The major gain of using a functional language is the ease with which abstraction can be layered over low‐level detail, improving both the readability of code and its tractability.
Malcolm Wallace, Colin Runciman
Softw. Pract. Exp.1