Hi, Am Donnerstag, den 11.09.2014, 12:25 +0200 schrieb Herbert Valerio Riedel:

UPDATE: I was just made aware that 'AutoDeriveTypeable' does in fact *not* require 'Typeable' to be in scope. So the proposal still stands, but with less motivation.

in that case, I’m -1. Typeable is not „plain, simple Haskell“, which is what I expect to be in the Prelude. I want a Haskell newbie to be able to read through the prelude and understand and make use of all of it. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

The one case I think Typeable should *always* be around for is creating new instances of Exception. The fact that AutoDeriveTypeable doesn't require Typeable in Prelude lessens my +1 a bit down to a +0.5, but I really want it to be easier for people to define their own exception types. On Thu, Sep 11, 2014 at 4:57 PM, Anthony Cowley wrote:

I'm -1 on this as I'm not yet convinced that reaching for Typeable should be such a quick decision that it deserves to always be in scope.

Anthony

...

On Sep 11, 2014, at 6:20 AM, Herbert Valerio Riedel wrote:

TL;DR =====

Re-export 'Data.Typeable.Typeable' from 'Prelude'

Motivation ==========

Since GHC 7.8 the ubiquitous 'Typeable' instances can only be auto-derived via `... deriving Typeable`, moreover there's a new extension `-XAutoDeriveTypeable` which implicitly auto-derives 'Typeable' for all defined types in modules for which that extension is enabled.

However, even if you enable `-XAutoDeriveTypeable` you still need to explicitly bring the 'Typeable' class into scope, with e.g.

import Data.Typeable (Typeable)

otherwise GHC complains with

Not in scope: type constructor or class ‘Typeable’

Since at this point it's become current practice to have 'Typeable' instances for most types, it would be beneficial to save an 'import Data.Typeable (Typeable)' line for the sole purpose of deriving such instances.

By having 'Prelude' re-export 'Typeable' from GHC 7.10 on (should this proposal be implemented) it would suffice to have a

default-extensions: -XAutoDeriveTypeable`

in the Cabal file and have 'Typeable' instance auto-derived for all types defined in a package w/o any source changes (unless there's a name-clash with 'Typeable')

Discussion period =================

The usual 2 weeks _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Am 11.09.2014 um 16:11 schrieb Felipe Lessa:

On 11-09-2014 11:05, Michael Snoyman wrote:

...

The one case I think Typeable should *always* be around for is creating new instances of Exception. The fact that AutoDeriveTypeable doesn't require Typeable in Prelude lessens my +1 a bit down to a +0.5, but I really want it to be easier for people to define their own exception types.

That's an argument for exporting Typeable from Control.Exception, since Prelude does not export Exception and friends.

For me the Typeable constraint of the Exception class is just an argument to not use implicit exceptions of IO, but instead use one of the various Exception monads with explicit exception types.

On Thu, Sep 11, 2014 at 4:25 PM, Brandon Allbery wrote:

On Thu, Sep 11, 2014 at 10:17 AM, Henning Thielemann wrote:

...

Am 11.09.2014 um 16:11 schrieb Felipe Lessa:

...

On 11-09-2014 11:05, Michael Snoyman wrote:

...

The one case I think Typeable should *always* be around for is creating new instances of Exception. The fact that AutoDeriveTypeable doesn't require Typeable in Prelude lessens my +1 a bit down to a +0.5, but I really want it to be easier for people to define their own exception types.

That's an argument for exporting Typeable from Control.Exception, since Prelude does not export Exception and friends.

For me the Typeable constraint of the Exception class is just an argument to not use implicit exceptions of IO, but instead use one of the various Exception monads with explicit exception types.

Not to mention that "...want it to be easier for people to define their own exception types" really makes me think something's gone wrong with the design somewhere. Exceptions ought to be ... exceptional, not common enough that people regularly need to define their own.

I thought the whole point of extensible exceptions was to define your own? That way you can catch them, instead of just piling them all together. I get that there are people who think you shouldn't use exceptions at all, but for the people who *do* use them, I think they should almost always define a new type for each one. Erik