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
wrote:
> Hi everyone,
>
> I would like to start working on a program that requires access
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
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
O
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:
> impo
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 st
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
avai
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
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:
http://www.haskell
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 con
On Thu, May 20, 2010 at 11:54 AM, Daniel Fischer
wrote:
>
> 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
> >
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 -> I
On 20 May 2010 16:50, Carlos Camarao 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 other Haskell feature
On Thu, May 20, 2010 at 12:25 PM, Max Bolingbroke
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 instance. This leads t
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. >
becomes >). However, I think that's a minor issue, and entity
resolution can be turned off in
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 -> St
On Thu, May 20, 2010 at 1:25 PM, Max Bolingbroke wrote:
> On 20 May 2010 16:50, Carlos Camarao 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
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 func
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 m
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 in
On 20 May 2010 21:16, Evan Laforge 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:
>
> -- explicitly
On 20 May 2010 13:10, Miguel Mitrofanov 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 (<*>) = ...
> instance
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 SomeExcepti
On 20 May 2010 20:30, Carlos Camarao 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 the Haskell spec says
On Thu, May 20, 2010 at 7:54 PM, Max Bolingbroke <
batterseapo...@hotmail.com> wrote:
> On 20 May 2010 20:30, Carlos Camarao 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 the original cla
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
> 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
Oscar Finnsson wrote:
> I got the GADT
>
> data DataBox where
> DataBox :: (Show d, Eq d, Data d) => d -> DataBox
>
> and I'm trying to get this to compile
>
> instance Data DataBox where
> gfoldl k z (DataBox d) = z DataBox `k` d
> gunfold k z c = k (z DataBox) -- not OK
As has been poin
On May 21, 2010, at 3:51 AM, Brent Yorgey wrote:
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
On 20/05/2010, at 9:53 AM, Richard O'Keefe wrote:
>
> The key point is the 'that would NATURALLY have', which I take
> to mean "as a result of type inference without any forcibly
> imposed type signatures".
In my second edition of Bird, the question just says: "Give examples of
functions with t
34 matches
Mail list logo
