[Haskell-cafe] Design question

[minh thu]

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".

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