Am 08.11.2010 18:55, schrieb Carlton Mills:

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.

The compatibility layer is good to compile existing code (and support testing). Using Text.ParserCombinators.Parsec from parsec 3 is no good idea, because it does not guarantee compatibility with parsec 2 (because type names like ParsecT are added.) Whenever you write a new parser and know that you will need features from parsec 3 you should (and easily can) directly use Text.Parsec. If you want to extend a parser written with parsec 2 with features not available in parsec 2 you may first try to use parsec 3. But changing your imports then, will be your least problem. In many cases you may even want to investigate other parser libraries, like attoparsec, polyparse or uulib. I think a new package parsec3 (without compatibility layer) belongs into this league of more advanced parser libraries (without blessing). Parsec 2 feels to be the right base library for the HP. Otherwise I agree with your points made. Christian

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 *To:* Don Stewart *Cc:* haskell-platform@projects.haskell.org; libraries@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 mailto:Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform