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
Hello,
I understand that with the proposed base package breakup [1], SYB will be
moved to a separate package. But I still don't know how this will reflect on
the development of the library. In particular:
1) Where is the source code going to be hosted? Here in Utrecht we currently
have a repository with several (cabalized) generic programming libraries,
SYB included. But maybe SYB will stay in the same repository as GHC?
2) Can development proceed independently of GHC, i.e. can a new version of
SYB be released without a new version of GHC?
3) How does the separation affect the automatic instance deriving mechanism?
Thanks,
Pedro
[1] http://hackage.haskell.org/trac/ghc/ticket/1338
On Tue, Aug 5, 2008 at 19:40, Ian Lynagh
On Tue, Aug 05, 2008 at 04:46:50PM +0200, Sean Leather wrote:
I think SYB should be extracted from 'base' into a package.
I'll be sending a message about this soon.
Thanks Ian
I understand that with the proposed base package breakup [1], SYB will be moved to a separate package. But I still don't know how this will reflect on the development of the library. In particular: 1) Where is the source code going to be hosted? Here in Utrecht we currently have a repository with several (cabalized) generic programming libraries, SYB included. But maybe SYB will stay in the same repository as GHC? I don't think it matters too much where it's hosted. For us it might be convenient if it was on darcs.haskell.org because it reduces the number of ways in which you can get stuck. But servers are fairly reliable so this probably isn't very important. 2) Can development proceed independently of GHC, i.e. can a new version of SYB be released without a new version of GHC? Yes, I think that independent development is part of the goal. The easiest way to achieve this is for SYB *not* to be a GHC "core package". That is, not needed to build GHC (or GHCi, or the GHC library). Then it's "just a library" like GtK or LibCurl, and you can upgrade it whenever you like. It's more complicated if it's a core package. For example, if the GHC API uses SYB to implement something, then package "ghc-6.9" will depend on package "SYB-2.7", and while you can also have SYB-3.2 installed the ghc-6.9 package will still use the "SYB-2.7". 3) How does the separation affect the automatic instance deriving mechanism? It think it'd make sense for the classes Data and Typable themselves to remain in a "core package", precisely because the deriving mechanism generates code for them. If you change the method signatures, the code has to change, for example. But all the library code layered on top can be in the SYB package. I hope I have this right! Simon
Hello,
Thanks for your answer. Replying below:
On Thu, Aug 21, 2008 at 11:16, Simon Peyton-Jones
I understand that with the proposed base package breakup [1], SYB will be moved to a separate package. But I still don't know how this will reflect on the development of the library. In particular:
1) Where is the source code going to be hosted? Here in Utrecht we currently have a repository with several (cabalized) generic programming libraries, SYB included. But maybe SYB will stay in the same repository as GHC?
I don't think it matters too much where it's hosted. For us it might be convenient if it was on darcs.haskell.org because it reduces the number of ways in which you can get stuck. But servers are fairly reliable so this probably isn't very important.
We might prefer to keep it in an SVN repository where we have other generic libraries, if that is not a big problem. If it is, it can always go to darcs.haskell.org anyway.
2) Can development proceed independently of GHC, i.e. can a new version of SYB be released without a new version of GHC?
Yes, I think that independent development is part of the goal. The easiest way to achieve this is for SYB **not** to be a GHC "core package". That is, not needed to build GHC (or GHCi, or the GHC library). Then it's "just a library" like GtK or LibCurl, and you can upgrade it whenever you like.
It's more complicated if it's a core package. For example, if the GHC API uses SYB to implement something, then package "ghc-6.9" will depend on package "SYB-2.7", and while you can also have SYB-3.2 installed the ghc-6.9 package will still use the "SYB-2.7".
I think indeed having it outside of the core is the best thing.
3) How does the separation affect the automatic instance deriving mechanism?
It think it'd make sense for the classes Data and Typable themselves to remain in a "core package", precisely because the deriving mechanism generates code for them. If you change the method signatures, the code has to change, for example. But all the library code layered on top can be in the SYB package.
Ok, that makes sense. Only any changes to methods in Data would need to wait for a new version of GHC. But those should be kept to a minimum, if any at all. It's just a pity that so many methods are inside the Data class (like gmapQ and friends). But then again, there is a reason for them to be there, and it's probably not a good idea to change those anyway. Most development should proceed by adding new things on top of the existing Data class core. What about instances of Data for the base types? Here I see a few possibilities: 1) No types have instances in core. Those could be in the SYB package, or the user could use stand-alone deriving to get them (if that is possible). 2) All types have instances in core, similar to the current Data.Generics.Instances situation. This implies that the situation discussed in [1] (inconvenient Data instances) will remain. 3) Something between the previous two, such as the 'standard' Data instances staying in core, and the others going to the SYB package (where they could be thought over, or separated into another module which is not imported by default). Pedro [1] http://www.haskell.org/pipermail/generics/2008-June/000347.html
1) Where is the source code going to be hosted? Here in Utrecht we currently have a repository with several (cabalized) generic programming libraries, SYB included. But maybe SYB will stay in the same repository as GHC? I don't think it matters too much where it's hosted. For us it might be convenient if it was on darcs.haskell.orghttp://darcs.haskell.org because it reduces the number of ways in which you can get stuck. But servers are fairly reliable so this probably isn't very important. We might prefer to keep it in an SVN repository where we have other generic libraries, if that is not a big problem. If it is, it can always go to darcs.haskell.orghttp://darcs.haskell.org anyway. I think we would very much prefer NOT to use SVN. We're already using darcs, and will shortly be using Git too. To have SVN too is a situation we'd like to avoid. Darcs or Git please! 3) How does the separation affect the automatic instance deriving mechanism? It think it'd make sense for the classes Data and Typable themselves to remain in a "core package", precisely because the deriving mechanism generates code for them. If you change the method signatures, the code has to change, for example. But all the library code layered on top can be in the SYB package. Ok, that makes sense. Only any changes to methods in Data would need to wait for a new version of GHC. But those should be kept to a minimum, if any at all. It's just a pity that so many methods are inside the Data class (like gmapQ and friends). But then again, there is a reason for them to be there, and it's probably not a good idea to change those anyway. Most development should proceed by adding new things on top of the existing Data class core. What about instances of Data for the base types? Here I see a few possibilities: 1) No types have instances in core. Those could be in the SYB package, or the user could use stand-alone deriving to get them (if that is possible). 2) All types have instances in core, similar to the current Data.Generics.Instances situation. This implies that the situation discussed in [1] (inconvenient Data instances) will remain. 3) Something between the previous two, such as the 'standard' Data instances staying in core, and the others going to the SYB package (where they could be thought over, or separated into another module which is not imported by default). I suspect it'd be better to have all the instances in the SYB package. If there are data types whose instances are sufficiently simple and unlikely to change that they can live in the same module as the Data class itself, then we can do that, but otherwise just put them in the package. S Pedro [1] http://www.haskell.org/pipermail/generics/2008-June/000347.html
On Thu, Aug 21, 2008 at 10:16:44AM +0100, Simon Peyton-Jones wrote:
Yes, I think that independent development is part of the goal. The easiest way to achieve this is for SYB *not* to be a GHC "core package".
Actually, base3-compat needs to re-export the SYB modules, as they were in base 3. So if base3-compat comes with GHC, then SYB needs to as well. It will still be possible to install newer versions of SYB, though. Thanks Ian
participants (4)
-
Ian Lynagh -
José Pedro Magalhães -
Sean Leather -
Simon Peyton-Jones