Hi Robert
OK. That's easy enough to change. Is the namespace consumption otherwise acceptable? Yep, pretty perfect I would say.
The only thing that slightly seems odd is the BinaryRead/BinaryWrite classes - I'm not sure if they are related to the "YHC.Bytecode.ModuleFormat.Version_1", or if they should be somewhere else in the namespace, or perhaps if they should be hidden altogether as an implementation detail. For the moment just leave them where they are though.
Well, I suppose that depends on what's meant by "in the main Yhc". I think its most valuable as a standalone library, so I'm not sure its a good idea to merge it into the Yhc compiler codebase, if that's what you mean. If you mean "in the Yhc darcs repo" that may still be problematic if I can't get commit access, because there are still a number of things I hope to do with this library. I just meant in the Yhc repo, as a separate and well defined library.
There are a few options to allow you to change the Yhc repo - you can set up your own darcs copy of yhc-devel and we can set up a cron script to pull every night, it might be possible to give you access (i remember reading something on the support pages once), or we might be best moving to darcs.haskell.org then everyone has an equal standing.
The only other issue is that I don't think this library is 100% ready for production use. I'd really like to write a good test suite before I feel comfortable with Yhc relying on it. Unfortunately I'm not sure when I'll have time to do this :-( Once Yhc relies on it you'll have a good testsuite automatically :) - it doesn't matter if it breaks Yhc for a few days in the meantime.
OK. I'll make the next release LGPL. Fantastic.
Thanks Neil