] Extending Type Classes
|
|
| The problem of refinement of type classes annoys me from time to time
| when I work on the NumericPrelude. It is an experimental type class
| hierarchy for mathematical types. Sometimes a new data type T shall be
| implemented and it turns out that you can implement
The problem of refinement of type classes annoys me from time to time
when I work on the NumericPrelude. It is an experimental type class
hierarchy for mathematical types. Sometimes a new data type T shall be
implemented and it turns out that you can implement only a part of all
methods
and corresponding
proposal [1]. But this proposal instead of allowing the change through
extending Type Classes forces client code to prepare for the new class
layout and then switch the classes to the new layout.
My goal is rather to allow direct changes in class hierarchy without
affecting client source
Dear Haskellers,
While trying to understand the interconnection and hierarchy behind
the important typeclasses, I stumbled upon the following question that
I am not able to answer:
There seems to be a hierachy of the type classes, in the sense, that
the more powerfull a class is, the more
to understand the interconnection and hierarchy behind
the important typeclasses, I stumbled upon the following question that
I am not able to answer:
There seems to be a hierachy of the type classes, in the sense, that
the more powerfull a class is, the more fleixblility you have for
combining them
of the type classes, in the sense, that
the more powerfull a class is, the more fleixblility you have for
combining them to complex programs. (Functor - Applicative -
Arrow[Choice,Plus,Apply,..] - Monad). It was nice to read in the
Typeclassopedia, that ArrowApply and Monad are equivalent, which
On Tue, May 28, 2013 at 04:42:35PM +0200, Johannes Gerer wrote:
By the same argument, could'nt I say, that any type class (call it
AnyClass) can do everything a Monad can:
instance AnyClass m = Monad (Cokleilsi m ())
That doesn't say that AnyClass can do anything a Monad can. AnyClass m =
That makes sense. But why does
instance Monad m = ArrowApply (Kleisli m)
show that a Monad can do anything an ArrowApply can (and the two are
thus equivalent)?
On Tue, May 28, 2013 at 5:17 PM, Tom Ellis
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:
On Tue, May 28, 2013 at 04:42:35PM
On Tue, May 28, 2013 at 05:21:58PM +0200, Johannes Gerer wrote:
That makes sense. But why does
instance Monad m = ArrowApply (Kleisli m)
show that a Monad can do anything an ArrowApply can (and the two are
thus equivalent)?
I've tried to chase around the equivalence between these two
Ok, now I see a difference, why Kleisli can be used to relate
typeclasses (like Monad and ArrowApply) and Cokleisli can not:
Kleisli m () _ = () - m _ is isomorphic to m _
whereas
Cokleisli m () _ = m _ - () is not.
Can somebody point out the relevant category theoretical concepts,
that are
What about these two very simple type classes. Are they equivalent?
(As Monad and ArrowApply)
(This actually compiles in GHC)
class Pointed f where
pure :: a - f a
class Unit f where
unit :: f a a
newtype UnitPointed f a = UnitPointed f a a
instance Unit f = Pointed (UnitPointed f) where
On Tue, May 28, 2013 at 09:09:48PM +0200, Johannes Gerer wrote:
What about these two very simple type classes. Are they equivalent?
[...]
class Pointed f where
pure :: a - f a
class Unit f where
unit :: f a a
newtype UnitPointed f a = UnitPointed f a a
instance Unit f = Pointed
at 09:09:48PM +0200, Johannes Gerer wrote:
What about these two very simple type classes. Are they equivalent?
[...]
class Pointed f where
pure :: a - f a
class Unit f where
unit :: f a a
newtype UnitPointed f a = UnitPointed f a a
instance Unit f = Pointed (UnitPointed f) where
On Tue, May 28, 2013 at 11:22:22PM +0200, Johannes Gerer wrote:
I have to ask, why was plausability and looking at the actual definition
(not just the types) not important for the other examples.
It would also be important to check the definitions in the other examples
too, but it's hard enough
()
incrTwiceC a = incrFooC a incrFooC a
Though, having reasonable default is not always possible.
For additional source of inspiration, might worth looking the
classic[2], and scrap your type classes article[3].
[1]:
http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/pragmas.html#specialize-pragma
What is the advance of using type classes? A function of the form
f :: Show a = ...
really has an implicit argument
f :: Show__Dict a - ...
that the compiler infers for us. So, the advantage of type classes is one
of convenience: we don't have to pass dictionaries around, or even figure
On Mon, Mar 4, 2013 at 5:50 PM, Rob Stewart robstewar...@gmail.com wrote:
...
-
import Control.Concurrent
-- API approach 1: Using type classes
class FooC a where
mkFooC :: IO a
readFooC :: a - IO Int
incrFooC :: a - IO ()
I recommend taking 'mkFooC' out of the typeclass
Hi,
I have a question about API design for Haskell libraries. It is a simple one:
functional object data structures encapsulating mutable state VS type
classes encapsulating mutable state
Here is a simple example. I present an API: using a type class `FooC`,
and aso as a data structure `FooT
Thanks everyone, I very much appreciate your help, and I think it did help.
I've spent the last few days implementing a substantial chunk of my system
using each of two different techniques. I've ended up going with and ADT
containing functions closed over the 'thing'. This seems to be the
for your convenience, the correct link:
https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 29/01/2013, at 12:43 PM, Bob Hutchison hutch-li...@recursive.ca wrote:
The immediate problem is mapping an input to the system, some json message
containing a reference to the 'thing' (like a key of some kind). I have to
take that reference and find the thing and operate on it. All
Today I thought it was about time to simplify how new 'things' of a certain
kind are added to the system. These things are some a cross between an event
and an assertion of a fact in a rule based system. There are many different
kinds of these things. I already have more than a dozen
Hi,
I'm relatively new to Haskell, and consider myself to be towards the beginner
side of the scale. Nevertheless, I've got this Haskell program I've been
working on that's sitting around 11k lines right now. The pattern has been to
let it grow to then knock it back by 'refactoring' or
If I understand your message well enough, I think you are looking for
GHC's `ExistentialQuantification` extension. Building heterogeneous
collections is a common example of what existential types are useful
for. Take a look at this wiki page [1]; there is an example of how to
accomplish this
On Mon, Jan 28, 2013 at 5:43 PM, Bob Hutchison hutch-li...@recursive.cawrote:
Now, this is how I got caught: it seems to be impossible to have
collections of things with a common type class if they have different
types. How is it that I've written that many lines of code in Haskell and
I'm
Prelude :t [[1,2],3]
you have a list with 2 elements:
- [1,2]
- 3
the type of [1,2] is [Integer]
the type of 3 is Integer
But all elements in a list must have the same type.
2012/12/27 Rustom Mody rustompm...@gmail.com:
On Thu, Dec 27, 2012 at 1:48 AM, Roman Cheplyaka r...@ro-che.info
Hi David, it looks like Rustom's aware that haskell's not lisp. What he
really wants methinks is a way to suppress type classes altogether! That or
a NoOverloadedNumerals extension.
-- Kim-Ee
On Thu, Dec 27, 2012 at 4:03 PM, David Virebayre dav.vire+hask...@gmail.com
wrote:
Prelude :t [[1,2
On Thu, Dec 27, 2012 at 8:26 PM, Kim-Ee Yeoh k...@atamo.com wrote:
Hi David, it looks like Rustom's aware that haskell's not lisp. What he
really wants methinks is a way to suppress type classes altogether! That or
a NoOverloadedNumerals extension.
-- Kim-Ee
I'm not really sure about
I don't know about the RebindableSyntax extension. But
Prelude :t [[1,2],3]
[[1,2],3] :: (Num [t], Num t) = [[t]]
The above only says that is is possible to have a list like [[1,2],3] if
you have for a Num t, [t] is also an instance of Num. But it doesn't
guarantee the existence of such an
* Rustom Mody rustompm...@gmail.com [2012-12-27 22:18:15+0530]
But now we are in for new surprises: Try out
f x y = x / y
Prelude :l f
[1 of 1] Compiling Main ( f.hs, interpreted )
f.hs:1:11: Not in scope: `/'
Failed, modules loaded: none.
Prelude (/)
It's because
Forgot to say: if you go the first route, you'll also need to define your
fromInteger in every module — the one from .ghci won't be in scope.
You can define
module MyPrelude (module Prelude, fromInteger) where
import Prelude hiding (fromInteger)
fromInteger = id
and import it instead.
On Thu, Dec 27, 2012 at 11:48 PM, Rustom Mody rustompm...@gmail.com wrote:
On Thu, Dec 27, 2012 at 8:26 PM, Kim-Ee Yeoh k...@atamo.com wrote:
What he really wants methinks is a way to suppress type classes
altogether! That or a NoOverloadedNumerals extension.
I'm not really sure about
: 2
*** type : Int
*** does not match : [Int]
So is there any set of flags to make haskell literals less polymorphic?
ie I want 3 to have type Int and 3.0 to have type Float.
This is of course for beginning students to not see type classes too early
You should note that GHCi uses extended defaulting rules as explained in
[1].
This means that a literal like 5 will only be of type Num a = a in GHCi
while in a normal Haskell program it will default to some concrete type
(Integer if there are no other constraints). Also, if you define x = 5
in a
Sorry, forgot the link:
http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/interactive-evaluation.html
Section 2.4.5 Type defaulting in GHCi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
* Rustom Mody rustompm...@gmail.com [2012-12-26 20:12:17+0530]
So is there any set of flags to make haskell literals less polymorphic?
Yes, there is!
% ghci -XRebindableSyntax
GHCi, version 7.6.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
On Thu, Dec 27, 2012 at 1:48 AM, Roman Cheplyaka r...@ro-che.info wrote:
* Rustom Mody rustompm...@gmail.com [2012-12-26 20:12:17+0530]
So is there any set of flags to make haskell literals less polymorphic?
Yes, there is!
% ghci -XRebindableSyntax
GHCi, version 7.6.1:
#7224: Polymorphic kind annotations on type classes don't always work as
expected
+---
Reporter: slindley | Owner:
Type: bug| Status
#7224: Polymorphic kind annotations on type classes don't always work as
expected
+---
Reporter: slindley | Owner:
Type: bug | Status
#7224: Polymorphic kind annotations on type classes don't always work as
expected
+---
Reporter: slindley | Owner:
Type: bug | Status
#7224: Polymorphic kind annotations on type classes don't always work as
expected
---+
Reporter: slindley | Owner:
Type: bug| Status
#7224: Polymorphic kind annotations on type classes don't always work as
expected
---+
Reporter: slindley | Owner:
Type: bug| Status
#7224: Polymorphic kind annotations on type classes don't always work as
expected
---+
Reporter: slindley | Owner:
Type: bug| Status
{-I am trying to apply model theoretic concepts to Haskell by considering type classes as theories and instances as models.Then the declaration of a sub-class specifies a signature morphism from the superclass to the subclass.In case below the theories (classes) are signature only (no default
On Thu, Aug 23, 2012 at 01:25:39PM +0100, Patrick Browne wrote:
If there is no model expansion could it be because of the constructor
discipline, which only allows variables, and constructors in the LHS
argument patterns.
Indeed, a variable name as a pattern on the LHS of a function
On 23/08/12, Brent Yorgey byor...@seas.upenn.edu wrote:fun1 returns 8 for all inputs. The fact that fun1's definition usesthe name 'constant' which happens to have the same name as somethingin scope is irrelevant. For example, this is precisely the same as the above:constant :: Intconstant =
, then the answer is no.
Consider, for instance, applicative functors and monads. We have the
(idealized) type classes:
class Functor a where...
class Functor a = Applicative a where...
class Applicative a = Monad a where...
However, there are strictly more Applicative instances than
Hi!
When writing library code that should work with both String and Text I
find my self repeatedly introducing classes like:
class ToString a where
toString :: a - String
class ToText a where
toText :: a - Text
(I use this with newtype wrapped value types backed by Text or
On 8 March 2012 10:53, Simon Hengel s...@typeful.net wrote:
When writing library code that should work with both String and Text I
find my self repeatedly introducing classes like:
class ToString a where
toString :: a - String
class ToText a where
toText :: a - Text
Text
* Simon Hengel s...@typeful.net [2012-03-08 10:53:15+0100]
When writing library code that should work with both String and Text I
find my self repeatedly introducing classes like:
[...]
How do you guys deal with that? Any thoughts?
If it's fine to depend on FunDeps, you can use ListLike.
On Thu, Mar 08, 2012 at 11:00:34AM +0100, Christopher Done wrote:
On 8 March 2012 10:53, Simon Hengel s...@typeful.net wrote:
When writing library code that should work with both String and Text I
find my self repeatedly introducing classes like:
class ToString a where
toString
On Thu, Mar 08, 2012 at 12:18:56PM +0200, Roman Cheplyaka wrote:
If it's fine to depend on FunDeps, you can use ListLike.
http://hackage.haskell.org/package/ListLike
How would that help with toText?
Cheers,
Simon
___
Haskell-Cafe mailing list
* Simon Hengel s...@typeful.net [2012-03-08 11:48:41+0100]
On Thu, Mar 08, 2012 at 12:18:56PM +0200, Roman Cheplyaka wrote:
If it's fine to depend on FunDeps, you can use ListLike.
http://hackage.haskell.org/package/ListLike
How would that help with toText?
toText = fromListLike
If you just need to go back and forth from String to Text, why do you need
to be generic? pack and unpack from Data.Text do the job.
Plus, in the way of what Christopher said, you can use the
OverloadedStrings extension. You can then use the string syntax at a place
that expects a text:
{-#
On Thu, Mar 08, 2012 at 12:37:31PM +0100, Yves Parès wrote:
If you just need to go back and forth from String to Text, why do you need
to be generic? pack and unpack from Data.Text do the job.
Always going through String or Text may (depending on what your
underlying representation is) be less
On Thu, Mar 08, 2012 at 12:54:13PM +0200, Roman Cheplyaka wrote:
* Simon Hengel s...@typeful.net [2012-03-08 11:48:41+0100]
On Thu, Mar 08, 2012 at 12:18:56PM +0200, Roman Cheplyaka wrote:
If it's fine to depend on FunDeps, you can use ListLike.
http://hackage.haskell.org/package/ListLike
* Simon Hengel s...@typeful.net [2012-03-08 13:20:22+0100]
On Thu, Mar 08, 2012 at 12:54:13PM +0200, Roman Cheplyaka wrote:
* Simon Hengel s...@typeful.net [2012-03-08 11:48:41+0100]
On Thu, Mar 08, 2012 at 12:18:56PM +0200, Roman Cheplyaka wrote:
If it's fine to depend on FunDeps, you
2012/1/16 Yin Wang yinwa...@gmail.com:
The typical example would be
instance Eq a = Eq [a] where
[] == [] = True
(a : as) == (b : bs) = a == b as == bs
_ == _ = False
It can handle this case, although it doesn't handle it as a parametric
instance. I suspect that we don't need the
Yin,
2012/1/14 Yin Wang yinwa...@gmail.com:
On Sat, Jan 14, 2012 at 2:38 PM, Dominique Devriese
dominique.devri...@cs.kuleuven.be wrote:
I may or may not have thought about it. Maybe you can give an example
of parametric instances where there could be problems, so that I can
figure out
The typical example would be
instance Eq a = Eq [a] where
[] == [] = True
(a : as) == (b : bs) = a == b as == bs
_ == _ = False
It can handle this case, although it doesn't handle it as a parametric
instance. I suspect that we don't need the concept of parameter
instances at all. We
that I can
figure out whether my system works on the example or not.
I'm surprised that you propose passing all type class methods
separately. It seems to me that for many type classes, you want to
impose a certain correspondence between the types of the different
methods in a type class
On Sat, Jan 14, 2012 at 2:38 PM, Dominique Devriese
dominique.devri...@cs.kuleuven.be wrote:
I may or may not have thought about it. Maybe you can give an example
of parametric instances where there could be problems, so that I can
figure out whether my system works on the example or not.
The
Yin,
2012/1/12 Yin Wang yinwa...@gmail.com:
I have an idea about type classes that I have been experimenting. It
appears to be a generalization to Haskell’s type classes and seems to
be doable. It seems to related the three ideas: type classes, implicit
parameters, and (typed) dynamic scoping
Hi all,
I have an idea about type classes that I have been experimenting. It
appears to be a generalization to Haskell’s type classes and seems to
be doable. It seems to related the three ideas: type classes, implicit
parameters, and (typed) dynamic scoping. But I don't know whether it
is good
Hi,
recently I tried the Typing Haskell in Haskell library. But I was
wondering why this program type checks:
-- plusMfun is standard '+': Num a = a - a - a
test = let Just classEnv = ( addCoreClasses : addNumClasses )
initialEnv
e = Ap ( Ap (Var +) (Lit $ LitStr 3)) (Lit $ LitStr
Is there a partial order on Haskell type classes?If so, does it induce any quasi-order relation on types named in the instances?In the example below types C and D have the same operation fThanks,Patdata C = C deriving Showdata D = D deriving Showclass A t where f::t-t f t = t instance A C
types because the subset
relation is.
On Mon, Nov 14, 2011 at 3:47 AM, Patrick Browne patrick.bro...@dit.ie wrote:
Is there a partial order on Haskell type classes?
If so, does it induce any quasi-order relation on types named in the
instances?
In the example below types C and D have the same
Why does GHC complains on the code below ? (I'll explain in a second a
requirement to do just so)
I get errors with ghc 6.12.1 and 7.0.2.
-
{-# LANGUAGE GADTs, TypeFamilies #-}
On Fri, Jul 22, 2011 at 12:12 PM, Serguey Zefirov sergu...@gmail.com wrote:
Why does GHC complains on the code below ? (I'll explain in a second a
requirement to do just so)
I don't why =(. But you can workaround by using
class CPU cpu where
data CPUFunc cpu
Note that you don't need
On Fri, Jul 22, 2011 at 11:12 AM, Serguey Zefirov sergu...@gmail.com wrote:
-
{-# LANGUAGE GADTs, TypeFamilies #-}
class CPU cpu where
type CPUFunc cpu
data Expr cpu
I just had a problem closely related to this on StackOverflow [1]
which was explained beautifully by cammcann.
The problem is that because type CPUFunc cpu is located inside the
definition of the class CPU it creates the illusion that they are
somehow tied together where CPUFunc is somehow in the
2011/7/22 Dan Doel dan.d...@gmail.com:
On Fri, Jul 22, 2011 at 11:12 AM, Serguey Zefirov sergu...@gmail.com wrote:
GHC cannot decide what instance of FuncVars to use. The signature of
funcVars is:
funcVars :: FuncVars cpu = CPUFunc cpu - [String]
This does not take any arguments that
2011/7/22 Felipe Almeida Lessa felipe.le...@gmail.com:
On Fri, Jul 22, 2011 at 12:12 PM, Serguey Zefirov sergu...@gmail.com wrote:
Why does GHC complains on the code below ? (I'll explain in a second a
requirement to do just so)
I don't why =(. But you can workaround by using
class CPU
On Fri, Jul 22, 2011 at 4:11 PM, Serguey Zefirov sergu...@gmail.com wrote:
But cpu variable is the same in all places. If we don't dive into
CPUFunc reduction (to Int or whatever) we can safely match funcVars
argument and unify cpu.
This is the case when we write generic functions over type
On 6/6/11 7:05 PM, Casey McCann wrote:
On Mon, Jun 6, 2011 at 5:32 PM, Matthew Steelemdste...@alum.mit.edu wrote:
branchApplicative = liftA3 (\b t f - if b then t else f)
This definition doesn't satisfy the laws given for the Branching
class; it will execute the effects of both branches
On Sun, Jun 5, 2011 at 12:51 PM, KC kc1...@gmail.com wrote:
If new intermediate classes crop up then there would be no point in fixing
class (Applicative m) = Monad m where
since it would have to be changed if new intermediate classes are found.
You might check out a few articles regarding
On Mon, Jun 6, 2011 at 4:05 PM, Casey McCann syntaxgli...@gmail.com wrote:
ArrowChoice and ArrowApply are conceptually distinct and I expect
there are instances of the former that have no possible instance for
the latter. Branching vs. Monad I am much less certain of.
For a real-time or
On Tue, Jun 7, 2011 at 6:14 AM, Casey McCann syntaxgli...@gmail.com wrote:
On Mon, Jun 6, 2011 at 7:55 PM, David Barbour dmbarb...@gmail.com wrote:
Earlier forms of my reactive demand programming model [1] - before I
switched to arrows - would qualify. The model has limited side-effects
Hello,
In a recent thread, it has been asserted that defining type class is
something you seldom need when programming in Haskell.
There is one thing that as non-professional Haskell programmer I found
type-classes useful for: Testing. This is probably very OO and is pretty
much influenced
Is this badly designed code that tries to mimic OO in a functional setting?
If the answer is yes, how could I achieve same result (eg. testing the code
that does command REPL) without defining type classes?
Here's how I do it:
data InteractiveState = InteractiveState {
state_read :: IO
On Tue, Jun 7, 2011 at 10:32 PM, Evan Laforge qdun...@gmail.com wrote:
Is this badly designed code that tries to mimic OO in a functional
setting?
If the answer is yes, how could I achieve same result (eg. testing the
code
that does command REPL) without defining type classes?
Here's
Here's how I do it:
data InteractiveState = InteractiveState {
state_read :: IO Command
, state_write :: Result - IO ()
}
How about :
data InteractiveState io = InteractiveState {
state_read :: io Command
, state_write :: Result - io ()
}
I guess you could, but I like it
of the reasons to use type classes. In fact,
you'll find a somewhat more general variety of it on Hackage in a
couple of forms, the one I'm most familiar with being MonadPrompt.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman
Is this badly designed code that tries to mimic OO in a functional
setting? If the answer is yes, how could I achieve same result (eg. testing
the code that does command REPL) without defining type classes?
Why would that be badly designed? And why would that be more OO? IMO it is a
perfectly
) = CommandIO io where
readCommand :: io Command
writeResult :: CommandResult - io ()
This is in fact one of the reasons to use type classes. In fact,
you'll find a somewhat more general variety of it on Hackage in a
couple of forms, the one I'm most familiar with being MonadPrompt
On Sun, Jun 05, 2011 at 12:51:47PM -0700, KC wrote:
If new intermediate classes crop up then there would be no point in fixing
class (Applicative m) = Monad m where
since it would have to be changed if new intermediate classes are
found.
There actually is at least one intermediate class
On Mon, Jun 6, 2011 at 9:19 AM, Brent Yorgey byor...@seas.upenn.edu wrote:
On Sun, Jun 05, 2011 at 12:51:47PM -0700, KC wrote:
If new intermediate classes crop up then there would be no point in fixing
class (Applicative m) = Monad m where
since it would have to be changed if new
On Mon, Jun 6, 2011 at 12:19 PM, Brent Yorgey byor...@seas.upenn.edu wrote:
The idea is that Applicative computations
have a fixed structure which is independent of intermediate results;
Monad computations correspond to (potentially) infinitely branching
trees, since intermediate results
On Mon, Jun 6, 2011 at 3:39 PM, Casey McCann syntaxgli...@gmail.com wrote:
On Mon, Jun 6, 2011 at 12:19 PM, Brent Yorgey byor...@seas.upenn.edu wrote:
The idea is that Applicative computations
have a fixed structure which is independent of intermediate results;
Monad computations correspond to
On Mon, Jun 6, 2011 at 5:32 PM, Matthew Steele mdste...@alum.mit.edu wrote:
I think Branching is to Monad what ArrowChoice is to ArrowApply.
Branching allows the shape of the computation to depend on run-time
values (which you can't do with Applicative), but still allows only a
finite number
If new intermediate classes crop up then there would be no point in fixing
class (Applicative m) = Monad m where
since it would have to be changed if new intermediate classes are found.
I realize non-existence proofs are hard.
--
--
Regards,
KC
___
On 06/06/2011, at 5:51 , KC wrote:
If new intermediate classes crop up then there would be no point in fixing
class (Applicative m) = Monad m where
since it would have to be changed if new intermediate classes are found.
I realize non-existence proofs are hard.
Not as hard as
This is a question about the use of type classes in Haskell.
I get an error (below) when trying to compile the code (below and at
https://github.com/chrisdew/haskell-sandbox/blob/master/not_working_but_clean.hs
).
As someone just learning Haskell, I have tried following GHC's advice,
but I think
On 14/04/11 13:00, Chris Dew wrote:
class Stream a b c d where
(-) :: a - (b - c) - d
instance Stream (IO d) d (IO c) (IO c) where
f - g = f= g
instance Stream d d (IO c) (IO c) where
f - g = g f
instance Stream d d c c where
x - y = y $ x
I notice that in all
of a completely different type d.
In Neil's class the function relates to the type of the answer but not
to the input.
The difficult type classes in Haskell - Applicative, Monad, and
Arrows / Category - are related to some degree to fairly standard
combinators on functions. But they generalize
@Neil Brown - That did it. It's not the ideal solution, as all -
are 'coerced' into being 'IO x' (if the rightmost term is an 'IO x'.
But it'll do for the time being.
Many thanks,
Chris.
On 14 April 2011 13:50, Neil Brown nc...@kent.ac.uk wrote:
On 14/04/11 13:00, Chris Dew wrote:
class
(b -
c) and a result of a completely different type d.
In Neil's class the function relates to the type of the answer but not
to the input.
The difficult type classes in Haskell - Applicative, Monad, and
Arrows / Category - are related to some degree to fairly standard
combinators
On 14 April 2011 20:35, Chris Dew cms...@gmail.com wrote:
Could you suggest how these constraints could be expressed in the
Haskell type system?
Hi Chris
I'm afriad I'd have to decline - generally in Haskell implicit
lifters are problematic, so it isn't something I'd be looking to
solve.
Thanks, that link's very relevant to what I'm trying. For the time
being I'll accept a partial solution where the last two types are now
the same, and try to improve it when my knowledge of Haskell improves.
I really want (hello - bracket) in (hello - bracket -
putStrLn) to have a type of
Twan van Laarhoven wrote:
For reference, here the full signature of the core combinators:
data Event a
data Behavior a
instance Functor Behavior
instance Applicative Behavior
instance Functor Event
instance Monoid (Event a)
filter :: (a - Bool) - Event a - Event a
apply :: Behavior (a - b) -
1 - 100 of 676 matches
Mail list logo
