I am a newbie. Nearly 50 years of imperative programming has miss-trained my neurons. I am trying to retrain them.
1. Compatibility layers are good. They enable progress and reliability. A good compiler will inline them away. 2. The Haskell Platform should ensure that programming examples in the leading text books can compile. A section of the release notes might note the exceptions and provide example alternatives. 3. Sticking to Haskell 98 when one can is probably virtuous, but ... 4. The big mainframe vendors like IBM and Unisys have this problem continually - big customers may need the latest version of the OS and a 5yr old Data Base system. In the 1970's, when I worked with Unisys systems (Burroughs then) they had rules and expectations: a) All programs would be recompiled eventually. No object code older than 2 release cycles would be allowed to execute. The OS would issue warnings and make log entries when you ran programs that were about to expires. The file search utility had a command line option to list expiring code. b) The customer could plan on using older compilers and older versions of the Data Base system on new OS releases. The customer accepted the obligation to upgrade by recompiling. - The vendors rules/customer expectations are probably more precise and explicit now. Finally, I would like to thank the people who make HP possible. When I tried to learn Haskell (pre HP) I gave up on trying to install interesting packages. Now, with HP, the base packages all install with their proper compiler quickly and simply. I don't have enough experience to help out, other than test installation of pre-releases on my Macs. But we all should do what we can to support the HP. Thank you, Carlton Mills, Urbana, Illinois ________________________________ From: Christian Maeder <christian.mae...@dfki.de> To: Don Stewart <d...@galois.com> Cc: haskell-platform@projects.haskell.org; librar...@haskell.org Sent: Mon, November 8, 2010 6:51:38 AM Subject: Re: Haskell Platform decision: time to bless parsec 3? I still favor parsec 2 over parsec 3 because a) parsec 3 is no longer haskell98 (as major parts of parsec 2 are) b) I don't like the compatibility layer (modules with re-exports) of parsec 3 for parsec 2 Without the compatibility layer (b) and making the package a new major version of parsec, we would probably not discuss this issue. I think the maintainers of "parsec 3" should create new package "parsec3" without the compatibility layer. A new package parsec2 was already created. There are simply no blessed parser packages! The problem is that so many package simply have "parsec" as dependency, otherwise I would vote for removing parsec from HP (or vote for parsec2). Christian Am 06.11.2010 16:18, schrieb Don Stewart: > Hey all, > > This is a loose end in the package policy situation: when the HP has a > major upgrade, the policy is to do all major upgrades for any packages > contained in the HP, as long as they don't add new dependencies. > > One exception to this rule has been parsec, where parsec 2 was > considered "blessed" on an ad hoc basis. > > I propose we agree to remove this ad hoc rule, and thus the HP will ship > with parsec 3. > > Does anyone have concerns with this? > > -- Don _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
