Sarah Thompson's Lab Notebook

Representing cyclic data structures in Haskell

Tue, 22 Jul 2003 15:32:45 GMT

Here are some notes relating to a recent thread on haskell-cafe, started by yours-truly with this question:

------------------------
What is the best way to represent cyclic data structures in Haskell?

Lists are trivial. Trees are trivial. But what if the thing you're trying to represent is shaped like an electronic circuit, with a (possibly large) number of nodes connected by multiple arrows to other nodes? In an imperative language like C++, I'd probably just model the circuit directly, with objects representing nodes and pointers representing links between nodes. A good way to model this in Haskell is less obvious, however.

A simplistic approach would be to represent such a structure as a list of nodes, where each node contained a list of other connected nodes. Containing the actual nodes within the sub-lists probably isn't feasible -- some kind of reference would be necessary in order to get around chicken-and-egg problems with instantiating the data structure. But, in this case, it's not so easy to see how one could 'walk' the structure efficiently, because moving from node to node would involve quite horrible (possibly slow) lookups. In C++, I'd simply follow a pointer, which would be an extremely fast operation.

I would also need to implement efficient indexes into the data structure -- flat searching will be too slow for non-trivial amounts of data. In C++, I'd implement one or more external (probably STL-based) indexes that point into the main data structure.

How do people typically solve this problem at the moment? I know a few people out there have written hardware compilers in Haskell and similar languages, so there should be some experience of this in the community. I can probably work something out soon enough, but reinventing the wheel is never a great idea.
------------------------

Here is a potted series of responses, some of which are definitely worth following up in more detail:

------------------------
Hi Sarah,

Representing cyclic structures is indeed somewhat tricky in a pure functional language. The obvious representation (representing the link structure implicitly in an algebraic data type) doesn't work, because you can't obvserve cycles.

I recommend checking out two pieces of work in this area:

1. Martin Erwig's work on inductive representations of graphs:

Inductive Graphs and Functional Graph Algorithms, Martin Erwig
Journal of Functional Programming Vol. 11, No. 5, 467-492, 2001

available from:

http://cs.oregonstate.edu/~erwig/papers/abstracts.html#JFP01

2. Koen Claessen and David Sands' work on observable sharing:

Observable Sharing for Functional Circuit Description,
Koen Claessen, David Sands, published at ASIAN '99, in Phuket, Thailand

available from:

http://www.math.chalmers.se/~koen/Papers/obs-shar.ps

Hope that helps,

-Antony

--
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
antony@apocalypse.org http://www.apocalypse.org/pub/u/antony
------------------------
Lazy evaluation means that you can embed nodes directly in a cyclic structure, even though that would appear to create an indefinite regression. In order to detect cycles, one might add a node identifier. Here's a simple example:

[[
-- spike-cyclicstructure.hs

data Node = Node { nodeid :: String, adjacent :: [Node] }

instance Eq Node where n1 == n2 = nodeid n1 == nodeid n2

instance Show Node where show = nodeid

findPaths :: Node -> Node -> [[Node]]
findPaths fromNode toNode = map reverse $ findPaths1 [] fromNode toNode

findPaths1 :: [Node] -> Node -> Node -> [[Node]]
findPaths1 beenThere fromNode toNode
| fromNode == toNode = [fromNode:beenThere]
| otherwise = concat [ findPaths1 (fromNode:beenThere) nextNode toNode
| nextNode <- adjacent fromNode
, not ( nextNode `elem` beenThere ) ]

n1 = Node "n1" [n2,n3,n4]
n2 = Node "n2" [n1,n3,n4]
n3 = Node "n3" [n1,n2]
n4 = Node "n4" [n1,n2]

test1 = findPaths n1 n2 -- [[n1,n2],[n1,n3,n2],[n1,n4,n2]]
test2 = findPaths n1 n3 -- [[n1,n2,n3],[n1,n3],[n1,n4,n2,n3]]
]]

One (crude) way to think about this is that a mention of a value in haskell behaves in some ways like a pointer to that value in (say) C.

If you don't want to assign unique identifiers by hand, you could use a state transformer monad to generate them for you.

#g
--
Graham Klyne
<gk@ninebynine.org>
PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E
------------------------
You _might_ find some useful ideas in

Franklyn Turbak and J. B. Wells. Cycle Therapy: A Prescription for Fold and
Unfold on Regular Trees. Third International Conference on Principles and
Practice of Declarative Programming. ACM, 2001.
http://cs.wellesley.edu/~fturbak/pubs/ppdp01.html
http://cs.wellesley.edu/~fturbak/pubs/index.html

Stefan Kahrs. Unlimp: Uniqueness as a leitmotiv for implementation. In M.
Bruynooghe and M. Wirsing, editors, Proc. Programming Language Implementation
and Logic Programming, Lecture Notes in Computer Science 631, 115--129, 1992.
http://citeseer.nj.nec.com/kahrs92unlimp.html

Chris Milton
(busy processing MILSTRIPs in Perl)

=====
Christopher Milton
cmiltonperl@yahoo.com
??????????????????????????
--Matsuo Bashou
------------------------
G'day all.

On Mon, Jul 07, 2003 at 04:04:17PM +0100, Sarah Thompson wrote:

>>> > I would also need to implement efficient indexes into the data structure
>>> > -- flat searching will be too slow for non-trivial amounts of data. In
>>> > C++, I'd implement one or more external (probably STL-based) indexes
>>> > that point into the main data structure.

I replied:

>> The direct Haskell equivalent is to use Refs; either IORefs or
>> STRefs. (I'd personally use IORefs, but that's because I like
>> having IO around.) Dereferencing an IORef is a constant-time
>> operation, just like chasing a pointer in C.

I forgot to give an example.

Suppose you want some kind of electronic circuit, as you suggested.
Abstractly, you want something like this:

data Node
= Node NodeState [Component]

data Component
= Resistor ResistorCharacteristics Node Node
| Transistor TransistorCharacteristics Node Node Node
| {- etc -}

You can make this indirect in introducing refs:

type NodeRef = IORef Node
type ComponentRef = IORef Component

data Node
= Node NodeState [ComponentRef]

data Component
= Resistor ResistorCharacteristics NodeRef NodeRef
| Transistor TransistorCharacteristics NodeRef NodeRef NodeRef

The data structures are mutable:

getNodeState :: NodeRef -> IO NodeState
getNodeState node
= do Node state _ <- readIORef node
return state

setNodeState :: NodeRef -> NodeState -> IO ()
setNodeState node state
= do modifyIORef (\Node _ cs -> Node state cs) node

and it's straightforward to construct an index into the middle
somewhere:

type NamedNodeIndex = FiniteMap String NodeRef

Cheers,
Andrew Bromage
------------------------
Hi Sarah,

On Mon, 2003-07-07 at 16:04, Sarah Thompson wrote:

>> What is the best way to represent cyclic data structures in Haskell?
>>
>> Lists are trivial. Trees are trivial. But what if the thing you're
>> trying to represent is shaped like an electronic circuit, ...
>> ...
>> How do people typically solve this problem at the moment? I know a few
>> people out there have written hardware compilers in Haskell and similar
>> languages, ...

You're right, this is a longstanding problem!

I've experimented with several solutions to it in Hydra, a pure
functional hardware description language whose aims include preserving
referential transparency, and also keeping within a natural functional
style. My view is that if you have to resort to encoding a C-style
solution in a functional language, then you might as well use C instead.

Anyway, there are several papers on Hydra that are relevant. The first
solution, described in a paper from 1988, is to build the circular
graphs in the obvious way and then to use a pointer-equality predicate
to traverse the graphs safely. Of course, this makes the hardware
description language impure, it breaks referential transparency, and it
has other drawbacks. You can find that paper on my web page, but it was
written before Haskell appeared, and it uses an older functional
language with different syntax.

I wrote a paper about the problem in 1992,
www.dcs.gla.ac.uk/~jtod/papers/1992-Netlist/ This paper discusses the
problems with the pointer-equality solution and introduces naming as a
pure alternative. The idea of naming is to give unique labels to some
of the nodes, so that you can build the circular graph in the usual way,
and you can also traverse the graph safely. This is a pure functional
solution, and it has a lot of advantages over adjacency lists, but it
does require that the labels are introduced correctly. The best way to
put the labels in is by a transformation.

Currently, Hydra uses an automated transformation implemented with
Template Haskell to introduce the names. I think this is the ideal
solution: it results in a very clean notation for specifying the
circuit, and it supports traversal of the graph, yet it preserves simple
equational reasoning and all the supporting algorithms are in a pure
functional style. I'm currently writing a paper on the details of this
solution. It won't be finished for some time, but there already exists
a brief survey of the solution, which you can find at:
www.dcs.gla.ac.uk/~jtod/drafts/ ("Embedding a hardware description
language in Template Haskell") This paper focuses on the way Hydra is
implemented as a domain specific language embedded in Haskell, and the
last part of it talks about the graph traversal issues. This is a
draft, submitted for publication, and any comments on it would be
welcome! (However, the actual method used in Hydra is considerably more
complex than what's presented in the draft paper, because there are a
number of other issues that need to be addressed in addition to just
traversing the circular graph safely.)

There are a lot of alternative approaches to the problem. They will be
compared in more detail in the paper-in-progress, but briefly they
include: (1) Using adjacency lists, which have the disadvantages that
you pointed out. (2) Using a monadic approach, which can be used in
several distinct ways to solve the problem, but which have a bad impact
on the specification style and the ease of reasoning about the circuit.
(3) Using impure solutions, such as the pointer equality method used in
the 1988 Hydra paper. Observable sharing (Claessen and Sands, 1999) is
identical to the solution that was implemented in Hydra in the mid 80's
and described in the 1988 paper; the difference is that they call the
approach "observable sharing" instead of "pointer equality".

Best wishes,
John O'Donnell

------------------------

>What is the best way to represent cyclic data structures in Haskell?

There used to be some work on direct cyclic representations at UCL:

Dynamic Cyclic Data Structures in Lazy Functional Languages
Chris Clack, Stuart Clayman, David Parrott
Department of Computer Science, University College London,
October 1995

The link to the project, from

http://www.cs.ucl.ac.uk/staff/C.Clack/research/report94.html

is broken, but the paper seems to be online at

http://www.cs.ucl.ac.uk/teaching/3C11/graph.ps

If you want to go for this direct cyclic representation, the
interplay with lazy memo functions is also interesting:

J. Hughes, Lazy memo-functions, Functional Programming
Languages and Computer Architecture, J-P. Jouannaud ed.,
Springer Verlag, LNCS 201, 129-146, 1985.

(lazy memo-functions remember previous input-output pairs
based only on pointer-info, which is sufficient to write
functions over cyclic structures that, instead of infinitely
unrolling the cycles, produce cyclic results)

(not online?-(

Claus

wxHaskell

Tue, 22 Jul 2003 14:50:15 GMT

This looks heavensent (if it works! -- need to try it and see!)

--------------

Announcement: wxHaskell 0.1
---------------------------

http://wxhaskell.sourceforge.net/

wxHaskell is a new portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.

wxHaskell is therefore build on top of wxWindows -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).

Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2500 methods in 500
classes with 1200 constant definitions.

wxHaskell has been build with GHC 6.0 on Windows, MacOS X and Unix
systems with GTK. A binary distribution is available for Windows (and
we are working on a binary release for MacOS X).

And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.

All the best,
Daan Leijen.

_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Arvind's talk [Fri 15 Aug, provisionally 09:30, room TBA (FW26?)]

Tue, 22 Jul 2003 14:39:46 GMT

Cross-posted from cprg-announce:

Bluespec: Why chip design can't be left to EE's

Arvind

CSAIL (formerly LCS and AI Lab)

Massachusetts Institute of Technology

A 5M-gate ASIC is common place in 180nm technology today. We may see 50M to
100M-gate ASICs within a decade as technology improves to sub 90nm. (Fully
custom-designed microprocessors are, of course, much denser and faster then
ASICs but also require dramatically more design resources). Numerous
problems related to process and design need to be solved before such large
chips will become commonplace. Some of these problems, e.g., leaky
transistors, porous oxide, controlling multiple Vt's are clearly in the
domain of EE's but computer scientists are much better equipped to solve
the new problems related to the design-in-the-large. Large designs have to
be conceived and executed in terms of a hierarchy of blocks. The hierarchy
cannot be constructed in an ad hoc manner but should use some method of
composition systematically. For example, the functionality of a proper
composition of blocks has to be derivable from the functionality of
individual blocks. Bluespec is a language/methodology that promotes
correctness-by-construction. Its underlying execution model is based on
atomic actions on state elements (flip-flops, registers, ...), i.e., any
legal behavior is explainable in a terms of a sequence of atomic actions on
the state. Bluespec has facilities for expressing highly parameterized
modules ('generic classes" in the language sense) and an expressive
language to compose modules. The expressivity of the language has no limits
because its semantics are orthogonal to hardware execution semantics -- the
source program is turned into a flat interconnection of modules by "static
elaboration" during the compile phase.

In this talk I will present Bluespec via examples and show some of the
designs done so far.

Bluespec is a joint work of people at MIT and Sandburst Corporation.

Arvind is the Johnson Professor of Computer Science and Engineering at the
Massachusetts Institute of Technology. As the Founder and President of
Sandburst, Arvind led the Company from its inception in June 2000 until his
return to MIT in August 2002. His work at MIT on high-level specification
and description of architectures and protocols using Term Rewriting Systems
(TRSs), encompassing hardware synthesis as well as verification, laid the
foundations for Sandburst. Previously, he contributed to the development of
dynamic dataflow architectures, and together with Dr R.S.Nikhil published
the book "Implicit Parallel Programming in pH". Arvind is an IEEE Fellow
and was awarded the Charles Babbage Outstanding Scientist Award in 1994. He
has received the Distinguished Alumni Awards from the Indian Institute of
Technology, Kanpur, and the University of Minnesota.

Lazy specialisation thesis

Tue, 22 Jul 2003 14:38:56 GMT

This looks interesting:

http://www-users.cs.york.ac.uk/mjt/thesis-thyer.pdf (temporary link),
see also:

http://www.cs.york.ac.uk/ftpdir/reports/ (permanent)

Alan Mycroft passed on the link. Looks interesting from the abstract:

This thesis describes a scheme to combine the benefits of lazy evaluation
with partial evaluation. By performing specializations only when needed
(lazily), the specialize-residualize decision is changed from being semantic
to operational. It is demonstrated that a completely lazy evaluator is
capable of eliminating towers of interpreters. The scheme is generalised,
devising a new implementation of optimal evaluation, and it is demonstrated
that optimal evaluators do not eliminate towers of interpreters.
It is argued that the concept of scope has too often been overlooked in the
lambda-calculus. A new system of depths is introduced in order to handle
the issue of scope. The new approach leads to a much richer understanding
of the issue of sharing in the lambda-calculus. Although optimal evaluators
are well known, it is argued that less well understood degrees of sharing,
in between the sharing of conventional functional languages and optimal
evaluators, are of more practical use. A new classification of possible
function body reduction strategies is shown to be analogous and orthogonal
to argument reduction strategies.

My Lab Notebook

Tue, 22 Jul 2003 14:28:21 GMT

I've created this second LiveJournal as a lab notebook. Don't expect to find any personal comments here -- this journal is purely intended as a convenient place to store notes, thoughts, links and other low grade meanderings related to my PhD studies. If you find anything of use here, you're welcome to it! ;-)

Sarah Thompson