Haskell Platform decision: time to bless parsec 3?
crmills_2000 at yahoo.com
Mon Nov 8 12:55:15 EST 2010
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
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.Maeder at dfki.de>
To: Don Stewart <dons at galois.com>
Cc: haskell-platform at projects.haskell.org; libraries at 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
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).
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 at projects.haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-platform