Haskell Platform decision: time to bless parsec 3?

Carlton Mills 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 
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.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
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 at projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.haskell.org/pipermail/haskell-platform/attachments/20101108/8f8625a3/attachment.htm 


More information about the Haskell-platform mailing list