On 20 May 2010 14:42, Tony Morris tonymor...@gmail.com wrote:
We all know that class (Functor f) = Monad f is preferable but its
absence is a historical mistake. We've all probably tried once:
instance (Functor f) = Monad f where
Do you mean the reverse of this (instance (Monad m) = Functor m
Ivan Miljenovic wrote:
On 20 May 2010 14:42, Tony Morris tonymor...@gmail.com wrote:
We all know that class (Functor f) = Monad f is preferable but its
absence is a historical mistake. We've all probably tried once:
instance (Functor f) = Monad f where
Do you mean the reverse of
OpenCV and its Haskell bindings
http://hackage.haskell.org/package/HOpenCV
should be able to talk to a webcam. There's an O'Reilly book about OpenCV.
Tom
On Wed, May 19, 2010 at 10:06 PM, Eitan Goldshtrom
thesource...@gmail.com wrote:
Hi everyone,
I would like to start working on a program
Then it would be:
class Functor f where
fmap :: (a - b) - f a - f b
class (Functor f) = Pointed f where
pure :: a - f a
class (Pointed f) = Applicative f where
(*) :: f (a - b) - f a - f b
class (Applicative f) = Monad f where
join :: f (f a) - f a
This would be a great idea,
That won't be a great idea; if I just want my monad to be declared as one, I
would have to write
instance Functor MyMonad where fmap = ...
instance Pointed MyMonad where pure = ...
instance Applicative MyMonad where (*) = ...
instance Monad MyMonad where join = ...
Compare this with
instance
I've compared and clearly the former is significantly superior :)
I'm rather interested if there are any sound suggestions to resolve the
general issue of retrospective type-class extension.
Miguel Mitrofanov wrote:
That won't be a great idea; if I just want my monad to be declared as
one, I
Ah thanks. Just what I'm looking for. Also thanks for the info about the
USB bindings
-Eitan
On 5/20/2010 12:06 PM, Tom Nielsen wrote:
OpenCV and its Haskell bindings
http://hackage.haskell.org/package/HOpenCV
should be able to talk to a webcam. There's an O'Reilly book about OpenCV.
Tom
With retrospective type-class extension in place whatever they look
like, wouldn't everyone would have to import the same retrospectively
extended instances (orphan retrospective extensions anyone?). Thus
there seems no benefit over recoding the hierarchy directly and
importing it, vis:
import
Hi,
I'm looking for a simple way to rewrite strings according to simple
composable rules like:
replace _ by \\(\\hole\\)
replace -n where n matches an integer by ^{n}
so that I can import some pretty-printed output into a LaTeX alltt
environment. I'm guessing that this nice functional stream
Am 20.05.2010 um 14:16 schrieb Tony Morris:
I've compared and clearly the former is significantly superior :)
I'm rather interested if there are any sound suggestions to resolve the
general issue of retrospective type-class extension.
I would like to have something like
parent class
This message presents, informally, a proposal to solve Haskell's MPTC
(multi-parameter type class) dilemma. If this informal proposal turns
out to be acceptable, we (I am a volunteer) can proceed and make a
concrete proposal.
The proposal has been published in the SBLP'2009 proceedings and is
On Thursday 20 May 2010 15:49:59, Roly Perera wrote:
Hi,
I'm looking for a simple way to rewrite strings according to simple
composable rules like:
replace _ by \\(\\hole\\)
replace -n where n matches an integer by ^{n}
so that I can import some pretty-printed output into a LaTeX alltt
Hello Roly
As Daniel Fischer says, there might not be a library to do this.
I would be tempted to start with a simple parser combinator library
and do something with the 'answer type' so it supports string
rewriting.
Dave Bayer was working with one in this thread on Beginners:
On Thursday 20 May 2010 16:34:17, Carlos Camarao wrote:
In the context of MPTCs, this rule alone is not enough. Consider, for
example (Example 1):
class F a b where f:: a-b
class O a where o:: a
and
k = f o:: (C a b,O a) = b
Type forall a b. (C a b,O a) = b can be considered to
On Thu, May 20, 2010 at 11:54 AM, Daniel Fischer
daniel.is.fisc...@web.dewrote:
On Thursday 20 May 2010 16:34:17, Carlos Camarao wrote:
In the context of MPTCs, this rule alone is not enough. Consider, for
example (Example 1):
class F a b where f:: a-b
class O a where o:: a
On Thu, May 20, 2010 at 11:53:09AM +1200, Richard O'Keefe wrote:
On May 20, 2010, at 3:18 AM, Brent Yorgey wrote:
On Wed, May 19, 2010 at 04:27:14AM +, R J wrote:
What are some simple functions that would naturally have the following
type signatures:
f :: (Integer - Integer) - Integer
On 20 May 2010 16:50, Carlos Camarao carlos.cama...@gmail.com wrote:
Using the available instances to resolve overloading is a tricky thing,
it's very easy to make things break that way.
Using the available instances is the natural, in fact the only way, to
resolve overloading.
AFAIK no
On Thu, May 20, 2010 at 12:25 PM, Max Bolingbroke
batterseapo...@hotmail.com wrote:
Available instances are not a natural addition to this list. In
particular, using that information can cause programs to become
untypeable when the module or *any module it imports transitively*
defines a new
Hi Joachim,
I have been playing around with this idea myself in TagSoup
(http://community.haskell.org/~ndm/tagsoup). The largest conceptual
problem I came across was that TagSoup decodes entities (i.e. gt;
becomes ). However, I think that's a minor issue, and entity
resolution can be turned off
I was wondering how to forcibly quiet down the API. I have a custom handler
in place, but when I call the function on failure both my handler gets
called and somewhere somehow errors get printed to the stderr, which I
really need to avoid.
My current code looks like
getModInfo :: Bool -
On Thu, May 20, 2010 at 1:25 PM, Max Bolingbroke batterseapo...@hotmail.com
wrote:
On 20 May 2010 16:50, Carlos Camarao carlos.cama...@gmail.com wrote:
Using the available instances to resolve overloading is a tricky thing,
it's very easy to make things break that way.
Using the
hi,
i tried this too, but i did not get it. a very nice workaround is to use
hint [1].
have fun
martin
[1]: http://hackage.haskell.org/package/hint
On 20.05.2010 20:05, Phyx wrote:
I was wondering how to forcibly quiet down the API. I have a custom
handler in place, but when I call the
On Thu, May 20, 2010 at 10:16:29PM +1000, Tony Morris wrote:
I've compared and clearly the former is significantly superior :)
I'm rather interested if there are any sound suggestions to resolve the
general issue of retrospective type-class extension.
Hi, my 'class aliases' proposal was
I've thought about that, but my specific problem is that I'm calling the
Haskell code compiled to a shared lib and then hPutStr is failing,
presumable because there is no valid stderr (and I would image also no stdin
or out).
So in order for me to use that method I would have to create a new file
Hi,
Unfortunately hint does not provide the functionality I require, and from
what I remember about hint they also use the GHC API, I guess the problem
here is the defaultErrorhandlers that is in initGhcMonad . I've been
wondering if I give my own implementation, one that doesn't do any printing
I wonder: Of cases where overload resolution via available instances
would be reasonable, how many would also make sense as a closed type
class? By comparison, it seems that many uses of OverlappingInstances
are really just trying to express a closed type class with one or more
default
On 20 May 2010 21:16, Evan Laforge qdun...@gmail.com wrote:
Someone recently described the HASP project, at
http://hasp.cs.pdx.edu/. It describes habit, a haskell like
language with some additions and subtractions. There are a couple
interesting extensions to 'instance' declarations:
--
On 20 May 2010 13:10, Miguel Mitrofanov miguelim...@yandex.ru wrote:
That won't be a great idea; if I just want my monad to be declared as one, I
would have to write
instance Functor MyMonad where fmap = ...
instance Pointed MyMonad where pure = ...
instance Applicative MyMonad where (*) =
Dear all,
I uploaded threads-0.1.0.1 to hackage. Threads is a small package that
lets you fork threads and wait for their result.
The basic interface is simply:
module Control.Concurrent.Thread where
data ThreadId α
forkIO ∷ IO α → IO (ThreadId α)
wait ∷ ThreadId α → IO (Either
On 20 May 2010 20:30, Carlos Camarao carlos.cama...@gmail.com wrote:
Consider instances defined in non-imported modules to be visible in the
current
context is not correct, I think...
I was under the impression that this was not specified, because
orphans are a bit of an oddity. But naturally
On Thu, May 20, 2010 at 7:54 PM, Max Bolingbroke
batterseapo...@hotmail.com wrote:
On 20 May 2010 20:30, Carlos Camarao carlos.cama...@gmail.com wrote:
... Also, the same fragilty occurs if FDs are used.
This remark is surprising to me. I thought the point of the FDs being
declared on
Maciej Piechotka wrote:
class (Monad m, Monad (IO' m)) = MonadIO m where
type IO' m :: * - *
liftIO :: IO a - IO' m a
liftM :: m a - IO' m a
The signature for liftIO betrays a problem. Since liftIO is a member
of a type class, when liftIO is used in code, the type checker has to
Hi Evan, hasn't EHC had something like this for a while with 'type
class directives'?
I dunno, I don't even know what ehc is. Is it this?
http://www.cs.uu.nl/wiki/Ehc/WebHome
I turned up a paper that mentioned type class directives, but I
haven't read it yet. In any case, the EHC page says
33 matches
Mail list logo
