2009/12/17 [email protected] <[email protected]>: > Hi all, > > thanks for your ideas so far. > >> I think you might be looking for too much sugar. I don't know much >> about your problem, but I would use approximately your approach and be >> straightforward: > > To bother you with some details: i am building a model for an SVG document. > http://chlor.svn.sourceforge.net/viewvc/chlor/trunk/haskell/Chlor/FileFormat/Svg/SvgDocument.hs > > There are many SVG elements, of which only a few are valid as the content of > each other SVG elements. > SvgDocumentElement defines the allowed subset for the SVG document. > > I want to generate a "DList Char" for all those sub-elements and finally > collapse them to one "DList Char" representing the whole SVG document. > So it's a bit more complicated than your "Either" example > > I need to manually efine such subset data structures for most SVG elements > which does not feel most elegant already. > Additionally instantiating a class for the subset structures, in order to > being able to iterate over them, feels even more clumsy. > > So i wonder whether i am missing a more clean approach to the problem > "easily combining data structures but also easy iteration over them".
Hi, I think your approach is right, even if it seems a bit heavy. After all, the reason it seems heavy maps directly to the very fact your modeling a typed hierarchy of elements. The typing will provide guarantee about the well-formed-ness of your data. You can take a look at the GraphViz package, or TH; you will see such hierarchies. Using generics (such a pointed by the first answer you received) can make it easier to traverse the hierarchy. As a side note, to generate the final textual representation of your SVG document, you might want to look at some XML packages on hackage, if you haven't done yet. Cheers, Thu _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
