headers
Daniel Peebles | 1 Feb 19:19
Picon
Gravatar

Re: Add meaningful instances to ZipList

I've created a ticket for this at http://hackage.haskell.org/trac/ghc/ticket/5787. I've been having some issues with my local install but should put a patch up very soon.


Dan

On Mon, Dec 19, 2011 at 5:32 PM, Brent Yorgey <byorgey <at> seas.upenn.edu> wrote:
On Sat, Dec 17, 2011 at 01:37:35PM -0500, Daniel Peebles wrote:
> I noticed that the ZipList newtype in Control.Applicative has no derived
> instances at all. We can't show a ZipList, check it for equality, or do
> anything to it except unpack it or treat it like an Applicative or Functor.
>
> It seems fairly uncontroversial to suggest adding some instances for it,
> but there are some minor questions to address: the obvious instances to add
> might be Eq, Ord, Show, Read, and possibly Typeable and/or Data. Are there
> any others I've missed? For the Read/Show instances, do we want manual ones
> that don't use the verbose record-style output? Since it's just defined as
> data ZipList a = ZipList { getZipList :: [a] } to get an easy accessor
> (does anyone actually use getZipList as a field for record updates?), it
> might be easier to write the projection manually and change the definition
> to data ZipList a = ZipList [a] with a separate getZipList function, so the
> deriving mechanism can give us a less noisy Show instance.

+1

-Brent

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Permalink | Reply | 0 comments |
headers
Ian Lynagh | 3 Feb 21:53
Picon
Gravatar

Proposal: Remove Control.OldException


Hi all,

We've had Control.OldException, and the new Control.Exception, since GHC
6.10.1, and since 6.12.1 using Control.OldException has given the
deprecation message
    Future versions of base will not support the old exceptions style.
    Please switch to extensible exceptions.

I propose that we now remove it from base.

If some people still cannot use the new Control.Exception for some
reason, then it could be maintained in an old-exception package.

Discussion deadline: 18 Feb 2012.

Thanks
Ian
Permalink | Reply | 11 comments |
headers
Felipe Almeida Lessa | 3 Feb 21:58
Picon
Gravatar

Re: Proposal: Remove Control.OldException

+1

--

-- 
Felipe.
Permalink | Reply | 2 comments |
headers
Henning Thielemann | 3 Feb 22:00
Picon

Re: Proposal: Remove Control.OldException


On Fri, 3 Feb 2012, Ian Lynagh wrote:

> We've had Control.OldException, and the new Control.Exception, since GHC
> 6.10.1, and since 6.12.1 using Control.OldException has given the
> deprecation message
>    Future versions of base will not support the old exceptions style.
>    Please switch to extensible exceptions.
>
> I propose that we now remove it from base.
>
> If some people still cannot use the new Control.Exception for some
> reason, then it could be maintained in an old-exception package.

I prefer to have an old-exception package. I guess it is the only way to 
cope with IO exceptions in a Haskell 98 way.
Permalink | Reply | 3 comments |
headers
Johan Tibell | 3 Feb 22:01
Picon
Gravatar

Re: Proposal: Remove Control.OldException

+1

Just out of curiosity, are there any major packages (e.g. in the HP) that still use old exceptions?

-- Johan

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Permalink | Reply | 1 comment |
headers
Bas van Dijk | 4 Feb 01:07
Picon
Gravatar

Re: Proposal: Remove Control.OldException

+1

Bas
Permalink | Reply | 1 comment |
headers
Ivan Lazar Miljenovic | 4 Feb 01:26
Picon
Gravatar

Re: Proposal: Remove Control.OldException

+1

--

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
IvanMiljenovic.wordpress.com
Permalink | Reply | 0 comments |
headers
shelarcy | 4 Feb 01:59
Picon
Gravatar

Re: Proposal: Remove Control.OldException

+1

--

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/
Permalink | Reply | 0 comments |
headers
Conal Elliott | 5 Feb 00:36
Gravatar

Oddity with 'cabal install' in GHC 7.4.1

Since upgrading to 7.4.1, if I 'cabal install' successfully and then 'cabal install' a second time without first doing a 'ghc-pkg unregister <package-name>', I get the following complaint:

cabal: The install plan contains reinstalls which can break your GHC
installation. You can try --solver=modular for the new modular solver that
chooses such reinstalls less often and also offers the --avoid-reinstalls
option. You can also ghc-pkg unregister the affected packages and run ghc-pkg
check to see the effect on reverse dependencies. If you know what you are
doing you can use the --force-reinstalls option to override this reinstall
check.

The only path I've found so far that's willing to rebuild or even say nothing needs rebuilding (when nothing does) is to 'ghc-pkg unregister' and then 'cabal install' again. I'm getting the same behavior on Red Hat 5 and Mac OS 10.6.8, both compiled from sources.

Does anyone know what's going on here?

-- Conal
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Permalink | Reply | 9 comments |
headers
Andres Löh | 5 Feb 06:51

Re: Oddity with 'cabal install' in GHC 7.4.1

Hi Conal.

On Sun, Feb 5, 2012 at 12:36 AM, Conal Elliott <conal <at> conal.net> wrote:
> Since upgrading to 7.4.1, if I 'cabal install' successfully and then 'cabal
> install' a second time without first doing a 'ghc-pkg unregister
> <package-name>', I get the following complaint:
>
> [...]

The warning is intended to prevent you from breaking your system
without knowing that you know that you're running a potentially
dangerous cabal invocation.

The --force-reinstalls flag should always make it build. If it
doesn't, it's a bug.

In addition, I'm planning to make the warning a little bit less
aggressive before the release.

> The only path I've found so far that's willing to rebuild or even say
> nothing needs rebuilding (when nothing does) is to 'ghc-pkg unregister' and
> then 'cabal install' again. I'm getting the same behavior on Red Hat 5 and
> Mac OS 10.6.8, both compiled from sources.

I'd be surprised if the OS matters. But as I said, I've not yet
encountered a situation where it wouldn't build given
--force-reinstalls.

Cheers,
  Andres
Permalink | Reply | 8 comments |

Gmane