[Haskell-cafe] Design question

minh thu noteed at gmail.com
Thu Dec 17 07:33:09 EST 2009

2009/12/17 haskell at kudling.de <haskell at kudling.de>:
> 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".


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

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.


More information about the Haskell-Cafe mailing list