Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: special polymorphic default of typeclass depending on
other typeclasses? (Silent Leaf)
2. Re: special polymorphic default of typeclass depending on
other typeclasses? (Silent Leaf)
3. lost a typeclass maybe? (Silent Leaf)
----------------------------------------------------------------------
Message: 1
Date: Thu, 29 Jun 2017 20:10:59 +0200
From: Silent Leaf <silent.le...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] special polymorphic default of
typeclass depending on other typeclasses?
Message-ID:
<cagfccjmnjqm2qdcd2vxpgcgarpajasyrogr7ywfpbakec75...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
typos in my previous message (including in the code), don't pay attention,
any error is an error :P
2017-06-29 20:08 GMT+02:00 Silent Leaf <silent.le...@gmail.com>:
> you're right my example is more like Show, it's because i change two times
> the order of input and output, and did not check at the end if it was what
> i wanted...
>
> Actually i did not mean constraints on instances, especially thereafter
> ad-hoc polymorphic instances.
> I rather meant what i said, as in default implementation (as in, right
> inside the body of the class).
> like that:
>
> class Foo a where
> bar :: a -> String
> bar :: Show a => a -> String
> bar = show -- default implementation: in other terms, if you define an
> instance without defining this method
>
> the idea would be then that if you have Foo (), you can either implement a
> special version, or leave it to show. mind you i'm not even sure we can
> define an instance without any specific implementation of method?
>
> --that would be allowed:
> instance Show => Foo () where
> -- nothing, if it's even legal by default
>
> -- and of course that would be allowed to if someone wanted a special
> function bar :: Foo () => () -> String
> instance Foo () where
> bar = ....
>
> obviously, i do not mean *both* instances of Foo (), just, one or the
> other. it would merely be a way to implement ad-hoc polymorphism onto
> *default implementations of methods*, that is, those inside the body of the
> class.
>
>
>
> 2017-06-29 19:45 GMT+02:00 David McBride <toa...@gmail.com>:
>
>> This is a common mistake that people who try to use type classes run
>> into. I remember banging my head against it pretty hard when I first
>> started out.
>>
>> There's this temptation that you should be able to write the following:
>>
>> class Foo a where
>> bar :: a -> String
>>
>> instance Read a => Foo a where
>> bar a = read a
>>
>> instance Foo () where
>> bar _ = "bar"
>>
>> But the problem with that is that now () applies to two conflicting
>> classes. It is both a Read and a Foo. So when you go bar (), which
>> instance should fire? The Foo instance or the Read () => Foo
>> instance?
>>
>> There are a multitude of ways you could try to resolve this. Let's
>> say obviously the Read constrainted instance is more specific, we
>> should use that. But then what if the user of your library happens to
>> have a instance Ord a => Foo a in his library, now which one of those
>> is more specific? Read or Ord?
>>
>> Because of all these ambiguities during type checking ghc doesn't even
>> look at the constraint. It would see instance Foo a, and instance Foo
>> (), and then say oh! those are overlapping instances because () could
>> apply to either class before you consider what constraints apply.
>>
>> There's actually several very in depth answers on stackoverflow for
>> this questions like this, such as this one:
>> https://stackoverflow.com/a/3216937/1500583 It might give you some
>> ideas on what to do about this.
>>
>> On Thu, Jun 29, 2017 at 1:15 PM, Silent Leaf <silent.le...@gmail.com>
>> wrote:
>> > hi,
>> >
>> > say i have the following typeclass:
>> >
>> > class Foo a where
>> > bar :: a -> String
>> >
>> > looks a lot like the Read typeclass, right? (at least i think it
>> should?)
>> > well say it's a different meaning (in other terms i can't or do not
>> want to
>> > use Read, but i'd like to implement a default version of bar for those
>> > instances that also implement Read. is there a way to do so?
>> >
>> > _______________________________________________
>> > Beginners mailing list
>> > Beginners@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>> >
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20170629/4b122604/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 29 Jun 2017 20:13:56 +0200
From: Silent Leaf <silent.le...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] special polymorphic default of
typeclass depending on other typeclasses?
Message-ID:
<cagfccjpzk+spen7yxvq72ifefa34r3wzjdticducnngij+u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sylvain Henri's link did the trick, that's what i was looking for (they
call it generic implementation).
in terms of terminology, is there an intrinsic difference between generic
and polymorphic?
2017-06-29 20:10 GMT+02:00 Silent Leaf <silent.le...@gmail.com>:
> typos in my previous message (including in the code), don't pay attention,
> any error is an error :P
>
> 2017-06-29 20:08 GMT+02:00 Silent Leaf <silent.le...@gmail.com>:
>
>> you're right my example is more like Show, it's because i change two
>> times the order of input and output, and did not check at the end if it was
>> what i wanted...
>>
>> Actually i did not mean constraints on instances, especially thereafter
>> ad-hoc polymorphic instances.
>> I rather meant what i said, as in default implementation (as in, right
>> inside the body of the class).
>> like that:
>>
>> class Foo a where
>> bar :: a -> String
>> bar :: Show a => a -> String
>> bar = show -- default implementation: in other terms, if you define an
>> instance without defining this method
>>
>> the idea would be then that if you have Foo (), you can either implement
>> a special version, or leave it to show. mind you i'm not even sure we can
>> define an instance without any specific implementation of method?
>>
>> --that would be allowed:
>> instance Show => Foo () where
>> -- nothing, if it's even legal by default
>>
>> -- and of course that would be allowed to if someone wanted a special
>> function bar :: Foo () => () -> String
>> instance Foo () where
>> bar = ....
>>
>> obviously, i do not mean *both* instances of Foo (), just, one or the
>> other. it would merely be a way to implement ad-hoc polymorphism onto
>> *default implementations of methods*, that is, those inside the body of the
>> class.
>>
>>
>>
>> 2017-06-29 19:45 GMT+02:00 David McBride <toa...@gmail.com>:
>>
>>> This is a common mistake that people who try to use type classes run
>>> into. I remember banging my head against it pretty hard when I first
>>> started out.
>>>
>>> There's this temptation that you should be able to write the following:
>>>
>>> class Foo a where
>>> bar :: a -> String
>>>
>>> instance Read a => Foo a where
>>> bar a = read a
>>>
>>> instance Foo () where
>>> bar _ = "bar"
>>>
>>> But the problem with that is that now () applies to two conflicting
>>> classes. It is both a Read and a Foo. So when you go bar (), which
>>> instance should fire? The Foo instance or the Read () => Foo
>>> instance?
>>>
>>> There are a multitude of ways you could try to resolve this. Let's
>>> say obviously the Read constrainted instance is more specific, we
>>> should use that. But then what if the user of your library happens to
>>> have a instance Ord a => Foo a in his library, now which one of those
>>> is more specific? Read or Ord?
>>>
>>> Because of all these ambiguities during type checking ghc doesn't even
>>> look at the constraint. It would see instance Foo a, and instance Foo
>>> (), and then say oh! those are overlapping instances because () could
>>> apply to either class before you consider what constraints apply.
>>>
>>> There's actually several very in depth answers on stackoverflow for
>>> this questions like this, such as this one:
>>> https://stackoverflow.com/a/3216937/1500583 It might give you some
>>> ideas on what to do about this.
>>>
>>> On Thu, Jun 29, 2017 at 1:15 PM, Silent Leaf <silent.le...@gmail.com>
>>> wrote:
>>> > hi,
>>> >
>>> > say i have the following typeclass:
>>> >
>>> > class Foo a where
>>> > bar :: a -> String
>>> >
>>> > looks a lot like the Read typeclass, right? (at least i think it
>>> should?)
>>> > well say it's a different meaning (in other terms i can't or do not
>>> want to
>>> > use Read, but i'd like to implement a default version of bar for those
>>> > instances that also implement Read. is there a way to do so?
>>> >
>>> > _______________________________________________
>>> > Beginners mailing list
>>> > Beginners@haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>> >
>>> _______________________________________________
>>> Beginners mailing list
>>> Beginners@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20170629/5157e39d/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 29 Jun 2017 20:36:26 +0200
From: Silent Leaf <silent.le...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: [Haskell-beginners] lost a typeclass maybe?
Message-ID:
<cagfccjozbmyrpnkuopwsiqwjy9s0rpcj5cgwnlgvwu_skam...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi,
i keep trying to find something that feels terribly obvious but i can't
make any link.
say i have a function of the following type:
foo :: (a, b) -> ([a], [b]) -> ([a], [b])
or perhaps more generally:
foo :: SomeClass f => f a b -> f [a] [b] -> f [a] [b]
is SomeClass supposed to be BiFunctor or something else?
clearly, what i want to do is to combine the elements of the first pair
into the elements of the second, preferrably without pattern matching, that
is, merely in function of (:).
i think the problem with bifunctor is that it seems to only allow the
application of both arguments in a separate fashion. but here the first
argument is in one block, that is (a,b).
i know, ofc we could do something like:
foo pair pairList = bimap (fst pair :) (snd pair:) pairList
or maybe use curry or whatever. but i'd like my pair to not need to be
unboxed!
is there not a way to not have to manually call fst and snd? are both of
these functions typeclass methods by any chance? then we could write a
generalized function that could work for any f = (:) or any kind of
pair-like thingy. mind you i'm not sure to which extent it would keep the
opacity of the type constructor (,).
especially, it's a bit like unboxing the Maybe type constructor: you can do
it manually by pattern matching, but when you have the exact same issue but
with IO, it's not possible anymore to unbox the underlying type
equally, i bet one could invent IO a b, in a way that you could not just
get a and b, but you could somehow implement
opaqueBimap :: (i -> k i) -> f a b -> f (k a) (k b) -> f (k a) (k b)
with here of course f = (,), k = [] or List, and (i -> k i) = (:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20170629/a78943a5/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 108, Issue 25
******************************************
