Hi,
It is quite likely that the error that you are getting with approach 2 is
because when you are constructing the `Combinator` value, there is not
enough type information to figure out how to solve the constraint (and it
sounds like this happens because there is not enough type information to
re
2012/5/17 Iavor Diatchki :
> Hello,
>
> The context in your example serves an important purpose: it records the fact
> that the behavior of the function may differ depending on which type it is
> instantiated with. This is quite different from ordinary polymorphic
> functions, such as `const` for
Hello,
The context in your example serves an important purpose: it records the
fact that the behavior of the function may differ depending on which type
it is instantiated with. This is quite different from ordinary
polymorphic functions, such as `const` for example, which work in exactly
the s
f
it,
within the limitations of a preprocessor). I'd be happy to help kick
ideas
around, if that's useful.
All the best
Conor
Simon
| -Original Message-----
| From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
| boun...@haskell.org] On Behalf Of Serguey Zefirov
|
| Sent: 06 May 2012 17:49
| To: haskell
| Subject: [Haskell-cafe] Data Kinds and superfluous (in my opinion)
| constraints contexts
|
| I decided to take a look at DataKinds extension, which became available
| in GHC 7.4.
|
| My main concerns is that I cannot close type classes for promoted data
I decided to take a look at DataKinds extension, which became
available in GHC 7.4.
My main concerns is that I cannot close type classes for promoted data
types. Even if I fix type class argument to a promoted type, the use
of encoding function still requires specification of context. I
consider t
