[Hugs-bugs] RE: the woes of non-cvs haskellers
To give just one concrete example, what packages do I recommend to someone wanting to learn a bit of Haskell, and do some graphics and perhaps windowing, on Windows?
- Hugs (Winhugs bug in current binary release, so better avoid that and use plain Hugs?) - HGL (does it work with latest Hugs/GHC, or do I need older versions? which ones?) - GHC (current binary release seems to have serious probs on some Windows versions; has also seen some rapid development breakage recently, e.g., TH syntax, forcing other packages to play catch-up just to get working again) - wxHaskell (works with ghc-6.0.1, will it work with 6.2? what about Hugs? what about ghc-6.4?) - some generic text-editor (but on Windows98, the way that .hs files are associated with Hugs/GHC cannot be modified in the standard dialogues, as they can for other associations, so how do I associate .hs files with an editor? I wouldn't want to recommend some beginner editing the registry for that purpose..)
The issues are usually small, but there are many of them, each package has its own, and all too often the response is "fixed in CVS, will be in next release".
Of course, the next release is a while a away and by that time, there'll be a different set of small issues plagueing the next set of binary releases. So, just getting someone started requires careful investigation/testing and some thinking (instead of: "just download and install the latest Haskell starters set").
It's been a rough ride in a few ways recently. But let me try to explain our policy and why it's a good compromise, and hopefully this will shed some light on why there might be problems going from GHC 6.0.1 to 6.2, for example. There's always going to be a tension between doing lots of bugfix releases and releasing new development versions so that people can get access to new features quickly. We only have limited resources - and we like to do a bit of development & research too, rather than just fixing bugs and doing releases all the time. So we arrived at the current policy, which is... We start a new *major* release every so often (eg. 6.2 is a major release). It has new features, and might change the interfaces to libraries and tools. At this point we branch the codebase. We then do a number of patchlevel releases (6.2.1, 6.2.2 etc.) that fix bugs *only*: i.e. it's highly unlikely that these releases introduce new bugs, and they definitely don't change interfaces. So those after stable binary releases can follow these patchlevels and get a monotonically improving experience :-) Meanwhile, we can continue development on the main branch (the HEAD). Due to our lack of resources, we can't do releases off both the stable branch and the HEAD (otherwise there would have been a 6.0.2). In due course, the HEAD turns into a new major release (6.4) and so on. We think this is a reasonable compromise and makes good use of the resources we've got. Remember that 6.2 is a new major release, and has had zero time to mature. So it's likely there are going to be bugs in it (eg. the Windows ME problem). 6.2.1 will follow shortly, and fix all/most of the issues that were reported without breaking code that works on 6.2. Also remember that certain features like TH are deemed experimental, and fixing their interfaces too soon would give us an undue maintenance burden. If you use experimental features, be prepared to do some conditional compilation based on compiler versions. Cheers, Simon
It's been a rough ride in a few ways recently. But let me try to explain our policy and why it's a good compromise, and hopefully this will shed some light on why there might be problems going from GHC 6.0.1 to 6.2, for example.
just to clarify: - I'm not complaining about your or anyone else's policy (well, not in this thread, anyway;-), especially when they're dictated by limited resources, and so many good things are produced in spite of such limitations! - I'm aware of the LIP, but it has been a long time in the making, probably because it tries to address lots of issues - what I'm trying to point out is that the current situation shows that there are some serious bugs in the system, even for the minimal core (Haskell starter pack = Haskell implementation + some GUI lib) - what I'm hoping is that there might be some small issues at the root, and that addressing those would give us a less bumpy ride until the LIP arrives at its goals
We start a new *major* release every so often (eg. 6.2 is a major release). It has new features, and might change the interfaces to libraries and tools. At this point we branch the codebase. We then do a number of patchlevel releases (6.2.1, 6.2.2 etc.) that fix bugs *only*: i.e. it's highly unlikely that these releases introduce new bugs, and they definitely don't change interfaces. So those after stable binary releases can follow these patchlevels and get a monotonically improving experience :-)
Knowing that, I tend to avoid the first version of each new major release:), but this general scheme has at least two problems at the moment, and especially the assumption in the last sentence above is, unfortunately, no longer true: 1. patchlevel releases have a lag time of a month or more even after "serious" bugs (remember that even trivialities like the winhugs problem look serious to beginners), suggesting that "just packaging up a patchlevel release" may not be as simple as perhaps it should be, even after the bugs are fixed. As patchlevel releases tend to appear only for the latest major release, because of the lack of resources, developers have to move with the major releases. 2. developers of tool X have little control over what versions of other packages/tools/implementations users have installed: - there are universities that only permit updates of the basic implementations between semesters/years, to provide stability - there are always new enthusiastic Haskell users, who naturally (try to) start from the latest set of versions - users generally use more than one tool/library, so they need to find a set of releases that works together - new major releases often fix bugs for which there's no simple work-around, so some developers depend on the latest implementation to get their package working - all developers suffer from lack of resources, so some packages might be updated less frequently to the changes introduced with the latest implementations Developers have to cater for what the installed base, summed over all their users, dictates. What makes the ride a bit bumpy at the moment is that there's no stable set emerging among the updates, so everyone is more or less forced to follow the latest developments in each of the packages they or their users are concerned with. As a tool developer, that means I'll get bug reports telling me that my tool doesn't build with the latest version of X, so I can't rest of my older stable version of X. As a Haskell promoter, that means I'm having a really hard time recommending what to download and install ("hugs, but don't use winhugs; ghc, but not the latest version; HGL/wxHaskell, perhaps, but one may not work with hugs, the other possibly not with ghc, or do they, and perhaps the versions and your system are important, hemm, let me check.."). It was the second role that alerted me to all the workarounds and uncertainties I had grown used to but which I can't impose on a newcomer.
We think this is a reasonable compromise and makes good use of the resources we've got.
Generally, it works very well - indeed part of the problem is that it's hard to keep up with you at times;) Cheers, Claus
Also remember that certain features like TH are deemed experimental, and fixing their interfaces too soon would give us an undue maintenance burden. If you use experimental features, be prepared to do some conditional compilation based on compiler versions.
The TH syntax leakage affected programs that never even used TH. But that's yesterday's news
participants (2)
-
Claus Reinke -
Simon Marlow