The composite design pattern implemented using record types, <br>where the named elements are the interface to the object<br><br>Overall, I think I agree with Tim that the record types are simpler to code. <br><br>I'm not sure, though, what would happen if I tried to add state to the types. With the previous example, using existentials to create a reference type that holds elements of a type class that matches the interface, I think that it would be natural to hold state by having that element stored in a mutable state variable, and replacing the held values.
<br><br>In any case:<br><br>Two methods, add and draw<br><br>> data Component = Component {<br>> draw :: String,<br>> add :: Component -> Component<br>> }<br><br>A constructor for the leaf type, which holds a string
<br><br>> leaf :: String -> Component<br>> leaf s = <br>> Component draw1 add1<br>> where draw1 = show s<br>> add1 _ = leaf s<br><br>the draw method for the composite type
<br>(because I was having trouble with layout and formating for 72 cols)<br><br>> compositeDraw :: [Component] -> String<br>> compositeDraw [] = "()"<br>> compositeDraw leaves = "(" ++ (foldr1 (++) $ map draw leaves) ++ ")"
<br><br><br>A constructor for the composite type, which holds a list of components<br>and dispatches to the contained elements<br><br>> composite :: [Component] -> Component<br>> composite cs =<br>> Component draw1 add1
<br>> where draw1 = compositeDraw cs<br>> add1 c = composite $ c:cs <br><br><br><br><div><span class="gmail_quote">On 2/27/07, <b class="gmail_sendername">Tim Docker</b> <<a href="mailto:twd_gg@dockerz.net">
twd_gg@dockerz.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Steve Downey wrote:<br>> interesting. it leads to something that feels much more like an object
<br>based, as opposed to a class based, system.<br>> as far as haskell is concerned, everything has the same type, even<br>though different instances have very different behavior.<br>> ....<br>> the question is, which plays nicer with the rest of haskell? that is, if
<br>i'm not committing to a closed dsl, which style is more likely to be<br>reusable against other libraries.<br><br>I suspect there's no right answer - it's a case of choosing the<br>best approach for the problem. As an example, my charting library
<br>(<a href="http://dockerz.net/software/chart.html">http://dockerz.net/software/chart.html</a>) uses the record of functions<br>approach for composing drawings:<br><br>data Renderable = Renderable {<br> minsize :: (Render RectSize)
<br> render :: (Rect -> Render ())<br>}<br><br>Tim<br><br><br><br><br></blockquote></div><br>