Function that behaves differently depending on which type classes the argument belong to
up vote
1
down vote
favorite
In Haskell, is there any way to declare function it behaves differently depending on whether the type of a argument is an instance of specific type class?
For example, can I define genericShow in the following example?
-- If type `a` is an instance of `Show`.
genericShow :: Show a => a -> String
genericShow = show
-- If type `a` is not an instance of `Show`.
genericShow :: a -> String
genericShow _ = "(Cannot be shown)"
> genericShow 3
"3"
> genericShow const
"(Cannot be shown)"
haskell
asked yesterday
user3749167
616
add a comment |
up vote
1
down vote
favorite
In Haskell, is there any way to declare function it behaves differently depending on whether the type of a argument is an instance of specific type class?
For example, can I define genericShow in the following example?
-- If type `a` is an instance of `Show`.
genericShow :: Show a => a -> String
genericShow = show
-- If type `a` is not an instance of `Show`.
genericShow :: a -> String
genericShow _ = "(Cannot be shown)"
> genericShow 3
"3"
> genericShow const
"(Cannot be shown)"
haskell
asked yesterday
user3749167
616
6
(1) Closely related: Check whether a type is an instance of Show in Haskell?; Use specialized implementation if a class instance is available. I'm not closing against those now because I'm not sure about which kind of answer would best fit here. (2) In the context of those two questions, the constraints-emerge package is also worth a shout. (3) In any case, as those discussions suggest, this isn't something to be undertaken lightly.
– duplode
yesterday
It helps me. Thanks a lot!
– user3749167
17 hours ago
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
In Haskell, is there any way to declare function it behaves differently depending on whether the type of a argument is an instance of specific type class?
For example, can I define genericShow in the following example?
-- If type `a` is an instance of `Show`.
genericShow :: Show a => a -> String
genericShow = show
-- If type `a` is not an instance of `Show`.
genericShow :: a -> String
genericShow _ = "(Cannot be shown)"
> genericShow 3
"3"
> genericShow const
"(Cannot be shown)"
haskell
asked yesterday
user3749167
616
In Haskell, is there any way to declare function it behaves differently depending on whether the type of a argument is an instance of specific type class?
For example, can I define genericShow in the following example?
-- If type `a` is an instance of `Show`.
genericShow :: Show a => a -> String
genericShow = show
-- If type `a` is not an instance of `Show`.
genericShow :: a -> String
genericShow _ = "(Cannot be shown)"
> genericShow 3
"3"
> genericShow const
"(Cannot be shown)"
haskell
haskell
asked yesterday
user3749167
616
asked yesterday
user3749167
616
asked yesterday
user3749167
616
asked yesterday
user3749167
616
asked yesterday
user3749167
616
616
6
(1) Closely related: Check whether a type is an instance of Show in Haskell?; Use specialized implementation if a class instance is available. I'm not closing against those now because I'm not sure about which kind of answer would best fit here. (2) In the context of those two questions, the constraints-emerge package is also worth a shout. (3) In any case, as those discussions suggest, this isn't something to be undertaken lightly.
– duplode
yesterday
It helps me. Thanks a lot!
– user3749167
17 hours ago
add a comment |
6
(1) Closely related: Check whether a type is an instance of Show in Haskell?; Use specialized implementation if a class instance is available. I'm not closing against those now because I'm not sure about which kind of answer would best fit here. (2) In the context of those two questions, the constraints-emerge package is also worth a shout. (3) In any case, as those discussions suggest, this isn't something to be undertaken lightly.
– duplode
yesterday
It helps me. Thanks a lot!
– user3749167
17 hours ago
6
6
(1) Closely related: Check whether a type is an instance of Show in Haskell?; Use specialized implementation if a class instance is available. I'm not closing against those now because I'm not sure about which kind of answer would best fit here. (2) In the context of those two questions, the constraints-emerge package is also worth a shout. (3) In any case, as those discussions suggest, this isn't something to be undertaken lightly.
– duplode
yesterday
(1) Closely related: Check whether a type is an instance of Show in Haskell?; Use specialized implementation if a class instance is available. I'm not closing against those now because I'm not sure about which kind of answer would best fit here. (2) In the context of those two questions, the constraints-emerge package is also worth a shout. (3) In any case, as those discussions suggest, this isn't something to be undertaken lightly.
– duplode
yesterday
It helps me. Thanks a lot!
– user3749167
17 hours ago
It helps me. Thanks a lot!
– user3749167
17 hours ago
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
No.
The closest you can get is to use Overlapping instances, with a catch-all instance for anything not having a more specific Show instance.
instance {-# OVERLAPPABLE #-} Show a where
show _ = "(Cannot be shown)"
Overlapping instances come with lots of caveats: see topics like 'orphan instances', 'Incoherent instances'. That's particularly awkward with Prelude classes like Show, because there's likely to be lots of instances hidden away in libraries.
As @duplode says, there are many dangers. Almost certainly there's a better way to achieve whatever it is you think you want.
answered 18 hours ago
AntC
542210
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
No.
The closest you can get is to use Overlapping instances, with a catch-all instance for anything not having a more specific Show instance.
instance {-# OVERLAPPABLE #-} Show a where
show _ = "(Cannot be shown)"
Overlapping instances come with lots of caveats: see topics like 'orphan instances', 'Incoherent instances'. That's particularly awkward with Prelude classes like Show, because there's likely to be lots of instances hidden away in libraries.
As @duplode says, there are many dangers. Almost certainly there's a better way to achieve whatever it is you think you want.
answered 18 hours ago
AntC
542210
add a comment |
up vote
1
down vote
No.
The closest you can get is to use Overlapping instances, with a catch-all instance for anything not having a more specific Show instance.
instance {-# OVERLAPPABLE #-} Show a where
show _ = "(Cannot be shown)"
Overlapping instances come with lots of caveats: see topics like 'orphan instances', 'Incoherent instances'. That's particularly awkward with Prelude classes like Show, because there's likely to be lots of instances hidden away in libraries.
As @duplode says, there are many dangers. Almost certainly there's a better way to achieve whatever it is you think you want.
answered 18 hours ago
AntC
542210
add a comment |
up vote
1
down vote
up vote
1
down vote
No.
The closest you can get is to use Overlapping instances, with a catch-all instance for anything not having a more specific Show instance.
instance {-# OVERLAPPABLE #-} Show a where
show _ = "(Cannot be shown)"
Overlapping instances come with lots of caveats: see topics like 'orphan instances', 'Incoherent instances'. That's particularly awkward with Prelude classes like Show, because there's likely to be lots of instances hidden away in libraries.
As @duplode says, there are many dangers. Almost certainly there's a better way to achieve whatever it is you think you want.
answered 18 hours ago
AntC
542210
No.
The closest you can get is to use Overlapping instances, with a catch-all instance for anything not having a more specific Show instance.
instance {-# OVERLAPPABLE #-} Show a where
show _ = "(Cannot be shown)"
Overlapping instances come with lots of caveats: see topics like 'orphan instances', 'Incoherent instances'. That's particularly awkward with Prelude classes like Show, because there's likely to be lots of instances hidden away in libraries.
As @duplode says, there are many dangers. Almost certainly there's a better way to achieve whatever it is you think you want.
answered 18 hours ago
AntC
542210
answered 18 hours ago
AntC
542210
answered 18 hours ago
AntC
542210
answered 18 hours ago
AntC
542210
542210
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53367056%2ffunction-that-behaves-differently-depending-on-which-type-classes-the-argument-b%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
6
(1) Closely related: Check whether a type is an instance of Show in Haskell?; Use specialized implementation if a class instance is available. I'm not closing against those now because I'm not sure about which kind of answer would best fit here. (2) In the context of those two questions, the constraints-emerge package is also worth a shout. (3) In any case, as those discussions suggest, this isn't something to be undertaken lightly.
– duplode
yesterday
It helps me. Thanks a lot!
– user3749167
17 hours ago