http://hackage.haskell.org/package/EdisonCore
the Edison packages come to mind as a previous effort in this space
On Wed, May 29, 2019 at 4:08 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:
> | having a common pattern for naming the operations certainly seems
> | nice. I am
; Andreas Klebinger <
> klebinger.andr...@gmx.at>; ghc-devs@haskell.org
> Subject: Re: Container type classes
>
> Yeah, there is really no relation between the two parameters of `Fun`,
> so you'd have to specify the intermediate type manually. For example:
>
> add3 :: foral
Cc: Brandon Allbery ; Andreas Klebinger
; ghc-devs@haskell.org
Subject: Re: Container type classes
Yeah, there is really no relation between the two parameters of `Fun`,
so you'd have to specify the intermediate type manually. For example:
add3 :: forall s. (Fun s s, Elem s ~ Int) => s ->
oo, but I guess
> this is not how type class resolution works.
>
> Cheers,
> Andrey
>
> -Original Message-
> From: Iavor Diatchki [mailto:iavor.diatc...@gmail.com]
> Sent: 30 May 2019 22:38
> To: Brandon Allbery
> Cc: Andrey Mokhov ; Andreas Klebinger
> ; ghc
c-devs@haskell.org
Subject: Re: Container type classes
This is how you could define `map`. This is just for fun, and to
discuss Haskell idioms---I am not suggesting we should do it. Of
course, it might be a bit more general than what you'd like---for
example it allows defining instances like `F
(Int -> Int) -> IntSet -> IntSet
>
>
>
> Cheers,
>
> Andrey
>
>
>
> *From:* Brandon Allbery [mailto:allber...@gmail.com]
> *Sent:* 30 May 2019 22:32
> *To:* Andrey Mokhov
> *Cc:* Artem Pelenitsyn ; Andreas Klebinger <
> klebinger.andr...@g
>>
>>
>>
>> Cheers,
>>
>> Andrey
>>
>>
>>
>> From: Artem Pelenitsyn [mailto:a.pelenit...@gmail.com]
>> Sent: 30 May 2019 20:56
>> To: Andrey Mokhov
>> Cc: ghc-devs@haskell.org; Andreas Klebinger
>> Subject: Re: Contain
-> Int) -> IntSet -> IntSet
Cheers,
Andrey
From: Brandon Allbery [mailto:allber...@gmail.com]
Sent: 30 May 2019 22:32
To: Andrey Mokhov
Cc: Artem Pelenitsyn ; Andreas Klebinger
; ghc-devs@haskell.org
Subject: Re: Container type classes
They can, with more work. You want indexed monads
19 20:56
> *To:* Andrey Mokhov
> *Cc:* ghc-devs@haskell.org; Andreas Klebinger
> *Subject:* Re: Container type classes
>
>
>
> Hi Andrey,
>
>
>
> FWIW, mono-traversable (
> http://hackage.haskell.org/package/mono-traversable) suggests decoupling
> IsSet and Funto
Klebinger
Subject: Re: Container type classes
Hi Andrey,
FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable)
suggests decoupling IsSet and Funtor-like.
In a nutshell, they define the IsSet class (in Data.Containers) with typical
set operations like member and singleton
Hi Andrey,
FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable)
suggests decoupling IsSet and Funtor-like.
In a nutshell, they define the IsSet class (in Data.Containers) with
typical set operations like member and singleton, union and intersection.
And then they tackle a
kering [mailto:matthewtpicker...@gmail.com]
Sent: 30 May 2019 18:26
To: Andrey Mokhov
Cc: ghc-devs@haskell.org; Andreas Klebinger
Subject: Re: Container type classes
If you care about performance then explicit dictionary passing is
going to be worse than using type classes.
At that point though, what do you gai
If you care about performance then explicit dictionary passing is
going to be worse than using type classes.
At that point though, what do you gain from using the module system as
you are just going to pass the same dictionaries into every function
and never change them.
So, for me, keep using
Hi all,
I tried to use type classes for unifying APIs of several similar data
structures and it didn't work well. (In my case I was working with graphs,
instead of sets or maps.)
First, you rarely want to be polymorphic over the set representation, because
you care about performance. You
| having a common pattern for naming the operations certainly seems
| nice. I am ambivalent if we do this with a class, or just name the
| operations the same way, and use the module system.
This was my reaction too. Consistent naming, yes. Using a type class, when
every invocation is at a
Hi,
having a common pattern for naming the operations certainly seems
nice. I am ambivalent if we do this with a class, or just name the
operations the same way, and use the module system. The type hackery
I was referring to was the type family for the set elements and map
keys you were
ghc-devs-requ...@haskell.org schrieb:
Hello,
I think refactoring to use consistent naming is a good idea, but I am
not sure about the class idea.
To see if it is viable, we should list the types in question and the
operations we'd like to overload.
I find that with containers there tend to be
17 matches
Mail list logo
