David: The issue with using an interface is how it is specified. The options seem to be either using HConf's approach, and requiring the user to provide the serialization functions, or using a typeclass. If the user has to provide the functions in the initial Dyre configuration, that reintroduces the entire issue that Dyre was designed to eliminate: now programs that aren't long-running enough to need persistent state still have to add extra verbosity because they aren't using it. And using the typeclass approach is basically indistinguishable from simply using Data.Binary, and defining a new instance declaration for its 'Binary' typeclass.
Currently, I favor the approach of allowing the user to use either Read/Show or Data.Binary, since it allows the user to define their serialization in the instance declaration of Data.Binary, if they choose to do so, but if you have another option, I'd be glad to consider it. - Will Donnelly On Aug 6, 1:15 pm, David Waern <david.wa...@gmail.com> wrote: > 2009/8/6 Jeff Wheeler <jeffwhee...@gmail.com>: > > > > > On Thu, Aug 6, 2009 at 12:45 AM, Gwern Branwen<gwe...@gmail.com> wrote: > > >> I've long wanted XMonad, Yi, and Autoproc to use a library for their > >> reconfiguration; how difficult do you think it would be to switch them to > >> using dyre? > > > After playing with integration for a bit, the only blocker I see is > > that Dyre uses Show/Read to store state, instead of Binary. I think > > Dyre should probably support Binary states before we can switch. > > Perhaps Dyre should just export some kind of interface for > serialization that you can instantiate the way you want? > > David --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list yi-devel@googlegroups.com http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
