Developing SYB, packaging issues
Hello all, This message focuses on a problem Claus mentioned before:
One other thing I meant to ask was about procedure, given that Syb is currently in base and hence under the library modification process. How is this going to combine with an active maintainer and some parts on hackage?
Claus
To be able to further develop SYB (see [1] for history), it's probably best to develop it as a separate package, which people can install, upgrade, etc. This would mean the library could be updated independently of GHC, and new GHC releases could then use the most recent version of the package. But how do these things merge? Can/should SYB be moved out of the base package? And, if this happens, can the library being developed as a separate package still use the automatic deriving mechanism? I'm sending this message to libraries@haskell.org too because I guess this problem might have shown up here before. Cheers, Pedro [1] http://search.gmane.org/?query=%22Owning+SYB%22&group=gmane.comp.lang.haskell.libraries&sort=revdate
Hi Pedro, To be able to further develop SYB (see [1] for history), it's probably best
to develop it as a separate package, which people can install, upgrade, etc. This would mean the library could be updated independently of GHC, and new GHC releases could then use the most recent version of the package.
Agreed. We talked about this offline, but I wanted to chime in with a +1 here. Just as it would help the GHC developers for a third party to develop and maintain SYB, it would help the developers and users for SYB to be distributed and available as a separate package.
But how do these things merge? Can/should SYB be moved out of the base package? And, if this happens, can the library being developed as a separate package still use the automatic deriving mechanism?
I think SYB should be extracted from 'base' into a package. It seems like the only technical thing that might prevent this extraction is the automatic deriving of Typeable and Data. Or does it prevent it? Can anyone clarify this? As a side note, might this work have an impact on the Haskell Platform? Thanks, Sean
participants (2)
-
José Pedro Magalhães -
Sean Leather