Haskell Programming, Case Study - Computer Science, Study notes of Computers and Information technologies

Case Study Graphs Initialisation Marking Traversal Indirect Representation Arrays hash tables maps haskell entities link order

Typology: Study notes

2010/2011

Uploaded on 09/06/2011

stifler_11
stifler_11 🇬🇧

4.6

(9)

272 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Haskell Study, slide 1
Case Study:
Stage in Haskell
Ian Holyer
Ian Holyer
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Haskell Programming, Case Study - Computer Science and more Study notes Computers and Information technologies in PDF only on Docsity!

Case Study:

Stage in Haskell

Ian Holyer Ian Holyer

Graphs

  • In implementing entities, the most obvious question isIn implementing entities, the most obvious question is what to do about 'graphs' (or 'networks') what to do about 'graphs' (or 'networks')
  • Entities form a graph with cycles, e.g.Entities form a graph with cycles, e.g. tree beach north south
  • It seems that graphs are naturally represented usingIt seems that graphs are naturally represented using pointers, and there are no pointers in Haskell pointers, and there are no pointers in Haskell
  • It turns out that there can be lots of problems withIt turns out that there can be lots of problems with using pointers to represent graphs using pointers to represent graphs

Problem 2: Marking

  • A lot of graph algorithms (e.g. shortest path) involveA lot of graph algorithms (e.g. shortest path) involve marking nodes to say they have been visited, or adding marking nodes to say they have been visited, or adding extra information about a node (such as its predecessor extra information about a node (such as its predecessor in the shortest path algorithm) in the shortest path algorithm)
  • Where do you put this extra information?Where do you put this extra information?
  • With nodes and edges represented as objects andWith nodes and edges represented as objects and pointers, you don't have much choice - you have to put pointers, you don't have much choice - you have to put the information inside the node objects the information inside the node objects
  • This pollutes the node type - it has to include fields toThis pollutes the node type - it has to include fields to support all the algorithms you are going to perform, support all the algorithms you are going to perform, instead of having a uniform node type with separate instead of having a uniform node type with separate generic algorithm modules generic algorithm modules

Problem 3: Traversal

  • Graph algorithms often involve traversing the nodes ofGraph algorithms often involve traversing the nodes of the graph by following edges the graph by following edges
  • But these algorithms are rarely purely local - you oftenBut these algorithms are rarely purely local - you often need global information about the graph need global information about the graph
  • Example: how do you traverse a graph if it is not bi-Example: how do you traverse a graph if it is not bi- connected? connected? a b c
  • If you start traversing from a, you never reach c, soIf you start traversing from a, you never reach c, so you need global info about which nodes are unreached you need global info about which nodes are unreached

Arrays, Hash Tables, Maps

  • It is rare to use arrays or hash tables in HaskellIt is rare to use arrays or hash tables in Haskell
  • There is a Data.Hashtable type, but it is I/O based, i.e.There is a Data.Hashtable type, but it is I/O based, i.e. it is sequential and not really functional, and therefore it is sequential and not really functional, and therefore not very easy to understand not very easy to understand
  • The standard libraries provide Maps only as lists ofThe standard libraries provide Maps only as lists of pairs with linear time performance: pairs with linear time performance:
  • [(0,a),(1,b),(2,c)] [(0,a),(1,b),(2,c)]
  • A better bet is to use Data.Map which is based onA better bet is to use Data.Map which is based on balanced trees and gives log(n) performance balanced trees and gives log(n) performance
  • However, technically, this is a GHC extension ratherHowever, technically, this is a GHC extension rather than standard (but scheduled to become standard) than standard (but scheduled to become standard)

Haskell Entities

  • So, for entities, let's choose an indirect implementationSo, for entities, let's choose an indirect implementation using Data.Map using Data.Map
  • An Entity can only be used in the context of a World,An Entity can only be used in the context of a World, which is a map from Ids to Entities which is a map from Ids to Entities
  • An Entity has an Id (a string, say) and its links form aAn Entity has an Id (a string, say) and its links form a map from link names to Ids map from link names to Ids data Entity = Entity (Map String Id) ... find :: Entity -> String -> Id find entity name = ... data Entity = Entity (Map String Id) ... find :: Entity -> String -> Id find entity name = ...

Link Order

  • As well as looking up link names, a structure is neededAs well as looking up link names, a structure is needed to record the order of the link names (creation order) to record the order of the link names (creation order)
  • The implementation given just uses a raw listThe implementation given just uses a raw list
  • A more sophisticated approach is to mirror theA more sophisticated approach is to mirror the LinkedHashMap structure of other languages: LinkedHashMap structure of other languages: Map String (Id, Int) Map Int (String, Int, Int) Map String (Id, Int) Map Int (String, Int, Int)
  • The first Map maps a link name to its Id, and to theThe first Map maps a link name to its Id, and to the indexes of the link, its predecessor, and its successor, indexes of the link, its predecessor, and its successor, in a simulated doubly linked list in a simulated doubly linked list
  • The second Map maps indexes to link namesThe second Map maps indexes to link names