
* Joachim Breitner
Hi,
I’m playing the “do we really need more packages with <10 symbols” card again:
"We"? This is about the time I stop pretending that there are any "we" with identical interests. "We" consist of many individuals, each one with his/her own agenda. Every decision is associated with different costs and benefits for each agent. In this case, the cost for me is very low (a couple of hours or less) and the benefit is huge — the package does exactly what I need it to do. The alternative you propose below is very costly (time spent arguing for the changes and waiting for them to be applied), and the benefit is the same at best. Of course, if you persuade me that my decision bears significant cost for others, I'll be a nice guy and cooperate (esp. if others are willing to put some effort, too, because it's them who the alternative decision will presumably benefit). But so far this cost is not obvious to me at all. Furthermore, *assuming* there is indeed cost to others, they can improve the situation directly. Indeed, I already did at least some part of the job (wrote the code that can be directly copied to the packages you mention). Why don't others do the second part of the job, that they like to say is almost trivial, and put their time and effort where their mouth is?
Am Mittwoch, den 05.02.2014, 13:23 +0200 schrieb Roman Cheplyaka:
base 4.7 (shipped with GHC 7.8) will have SomeAsyncException type that solves this problem.
asynchronous-exceptions is a new package that serves two purposes: * provide compatibility with older `base` versions that lack the `SomeAsyncException` type
isn’t that better done in base-compat, which provides exactly that: The scope of base-compat is to provides the same functionality as the latest version of base for a wider range of compilers.
* define convenient functions for catching only synchronous exceptions
If they are convenient, maybe they should go into base?
(I don’t mind such micro-packages if they are a vehicle for design space exploration and experiments, but I do think we should avoid too many packages aimed for general, stable, real-world-use if we can help it.)
Greetings, Joachim