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
> To bother you with some details: i am building a model for an SVG document.
> 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.
Haskell-Cafe mailing list