I've been looking into to this a bit myself, and have had trouble with the fact that the XML descriptions of the protocol are extremely C-centric. As in, the union types defined in the XML are C-unions, and I've seen a struct definition which uses padding-bytes to store semantically useful data.
Both of which are fine things to do in C, but a bit tricky to map onto Haskell. You should still be able to generate a large amount of data-types and serializing/deserializing code automatically. As for code generation, Language.Haskell.Syntax paired with Language.Haskell.Pretty is a pretty good way to do it, from what I can tell. On Mon, Mar 31, 2008 at 1:29 PM, Adam Langley <[EMAIL PROTECTED]> wrote: > 2008/3/31 Roman Cheplyaka <[EMAIL PROTECTED]>: > > > Especially I need help with "Milestones" section. I'm not quite sure how > > it should look like for such project. > > This would seem to be a commendable SoC project. I'm not sure that the > milestones are all that important - no plan ever survives contact with > reality. However, I'd suggest that these would be important aspects: > > * A working parser for the XCB (this involves choosing an XML parser > and getting useful data structures from it) > * A working Haskell code generator which outputs bindings for a > minimal subset of the functions > > (the last two need not be in Haskell, although I suspect that it would > be a good idea for them to be so) > > * The first, minimal, Haskell X client using XCB > * Having sensible bindings for 25%/50%/75% and 100% of the XCB interface. > > > > AGL > > -- > Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
