Hi, I was wondering about defining a restricted monad, and found out this
blog post: http://blog.omega-prime.co.uk/?p=127
In GHC 7.4.1 still the recommended way is using the rmonad package, right?
I guess the tricks with ConstraintKinds explained in the blog are used for
internal implementation
On Mon, Jun 04, 2012 at 11:35:20AM +0200, Ismael Figueroa Palet wrote:
Hi, I was wondering about defining a restricted monad, and found out this
blog post: http://blog.omega-prime.co.uk/?p=127
In GHC 7.4.1 still the recommended way is using the rmonad package,
right?
You can do it however
I'm playing around with a little program that implements a simple virtual
machine. I want to use a monad to represent machine state. I created a data
type for the machine (VM) and a monadic type for the monadic computations using
it. I declared this an instance of MonadState and Monad and
Am Mittwoch, den 16.09.2009, 03:23 -0700 schrieb Gregory Propf:
I'm playing around with a little program that implements a simple
virtual machine. I want to use a monad to represent machine state. I
created a data type for the machine (VM) and a monadic type for the
monadic computations
Well, it's almost always better to reuse as much code as possible. But I
don't think type is an answer here. I recommend using a newtype,
enabling GeneralizedNewtypeDeriving and deriving as much as possible:
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
...
newtype VM a =
VM {runVM :: State
newtype VMT m a =
VMT {runVMT :: StateT VMState m a}
deriving (Monad, MonadIO, MonadTrans, TransM, MonadState VMState)
works here (ghc-6.10.3)
On Wed, Sep 16, 2009 at 11:42 AM, Miguel Mitrofanov
miguelim...@yandex.ru wrote:
newtype VMT m a =
VMT {runVMT :: StateT VMState m a}
O, great. I didn't know you can write it this way.
Tom Nielsen wrote:
newtype VMT m a =
VMT {runVMT :: StateT VMState m a}
deriving (Monad, MonadIO, MonadTrans, TransM, MonadState VMState)
works here (ghc-6.10.3)
On Wed, Sep 16, 2009 at 11:42 AM, Miguel Mitrofanov
miguelim...@yandex.ru
DL Ah! So here's another quick question: if mzero is the identity
DL element, why isn't it part of the Monad class? Correct me if I'm
DL wrong but aren't Monads (in the mathematical sense) required an
DL identity element by definition?
Yes, they do. And this identity element is called return in
SOR I've heard that Monads are in some way like Monoids, hence the
SOR name. But I don't understand the explanation yet myself :(
Just compare:
Monoid: a set M with maps ident: M^0 - M and product: M^2 - M
(here M^0 is a one-element set)
Monad: a functor M with natural transformations return:
On 7/15/07, Miguel Mitrofanov [EMAIL PROTECTED] wrote:
SOR I've heard that Monads are in some way like Monoids, hence the
SOR name. But I don't understand the explanation yet myself :(
Just compare:
Monoid: a set M with maps ident: M^0 - M and product: M^2 - M
(here M^0 is a one-element set)
Hi everyone,
I've been playing with the parsers decribed in Monadic Parser Combinators
(http://www.cs.nott.ac.uk/~gmh/bib.html#monparsing) and I've gotten
stumped. I'm trying to get comfortable working monadically, so please
excuse my ignorance. Here's the relevant portions of my code:
data
On Sat, Jul 14, 2007 at 11:26:56PM -0400, David LaPalomento wrote:
I've been playing with the parsers decribed in Monadic Parser Combinators
(http://www.cs.nott.ac.uk/~gmh/bib.html#monparsing) and I've gotten
stumped. I'm trying to get comfortable working monadically, so please
excuse my
On 7/14/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
On Sat, Jul 14, 2007 at 11:26:56PM -0400, David LaPalomento wrote:
I've been playing with the parsers decribed in Monadic Parser
Combinators
(http://www.cs.nott.ac.uk/~gmh/bib.html#monparsing) and I've gotten
stumped. I'm trying to get
On Sun, Jul 15, 2007 at 12:03:06AM -0400, David LaPalomento wrote:
On 7/14/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Your base case is subtly wrong - it should be return [], not mzero.
Mzero always fails - mzero `mplus` x = x, by one of the MonadPlus laws.
Ah! So here's another quick
On Saturday 14 July 2007, Stefan O'Rear wrote:
On Sun, Jul 15, 2007 at 12:03:06AM -0400, David LaPalomento wrote:
On 7/14/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Your base case is subtly wrong - it should be return [], not mzero.
Mzero always fails - mzero `mplus` x = x, by one of the
Stefan O'Rear wrote:
On Sat, Mar 24, 2007 at 08:05:25PM +, Paul Johnson wrote:
strings, are instances of the Monoid class (i.e. they implement mplus in
the way you would expect). You just have to wrap a function around
Actually they don't.
[EMAIL PROTECTED]:/tmp$ ghc-6.4.2 -v0
Hi
I'm new here and this is my first mail to the list, so be gentle :)
I have some functions that build big strings by calling other functions and
appending the result, like
buildStuff =
func1 ++ func2 ++ func3 ++ func4
My idea is to have a monad with a concatenating , so that I can:
Leandro Penz wrote:
My idea is to have a monad with a concatenating , so that I can:
bulidStuff = do
func1
func2
func3
func4
You could do this, but it's easier to take advantage of the fact that []
is an instance of MonadPlus, and just use `mplus`.
b
My idea is to have a monad with a concatenating , so that I can:
bulidStuff = do
func1
func2
func3
func4
Leandro Penz
I actually did this recently for a project I have been working on.
First, an example:
output label a@(I.Add a1 a2 a3) = do
comment (show a)
mov' label eax a1
Leandro Penz wrote:
I have some functions that build big strings by calling other
functions and appending the result, like
buildStuff =
func1 ++ func2 ++ func3 ++ func4
The usual idiom is something like
buildStuff = concat [func1, func2, func3, func4]
Put the list elements on separate
On Sat, Mar 24, 2007 at 08:05:25PM +, Paul Johnson wrote:
strings, are instances of the Monoid class (i.e. they implement mplus in
the way you would expect). You just have to wrap a function around
Actually they don't.
[EMAIL PROTECTED]:/tmp$ ghc-6.4.2 -v0 -e 'main' X.hs
ABend
[EMAIL
Leandro Penz wrote:
buildStuff =
func1 ++ func2 ++ func3 ++ func4
My idea is to have a monad with a concatenating , so that I can:
bulidStuff = do
func1
func2
func3
func4
buildStuff = concat [
func1,
func2,
func3,
func4 ]
Remember, functional
Hi everyone,
Well, I'm trying to build a soccer server client and am using
Haskell. I thought I was muddling through well enough... but I have
some questions. I am using the Robot monad that I copied from Hudak's
book HSOE from page 272 (assuming I would understand it later).
Here's the
On 2004 September 19 Sunday 13:40, Andrew Harris wrote:
handleSeeRecord :: [SeeObjInfo_type] - RobotState - IO (RobotState, ())
handleSeeRecord seeobjlist p = do flaglist - return (morphToList
flagFinder seeobjlist)
balllist - return (morphToList
ballFinder
Hi
I was wondering if it was possible to write a function that allows changing
the state type of the Parser monad from Parsec.
The full parser type is: GenParser p s a, where p is the token type, s is the
state type and a is the return type of the monad. However, I mostly use
CharParser s a
In a local copy of Parsec.Prim I've added:
mapState :: (st1 - st2) - State tok st1 - State tok st2
mapState f (State i p u) = State i p $ f u
mapOkReply :: (st1 - st2) - Reply tok st1 a - Reply tok st2 a
mapOkReply _ (Error a) = Error a
mapOkReply f (Ok a s e) = Ok a (mapState f s) e
mapConsumed
i designed some basic functions, , mainly String
- [String], or similar with types, plus some more complex
datatypes.
Up to now; i was testing them on a basic database I
was creating in the core main, "by hand".
Then i added a basic parser with happy; and bingo;
my test database is now
On Sun, 13 May 2001, luc wrote:
i designed some basic functions, , mainly String - [String], or similar with types,
plus some more complex datatypes.
Up to now; i was testing them on a basic database I was creating in the core main,
by hand.
Then i added a basic parser with happy; and
Reg writes:
This little problem raises two challenges for compiler developers:
(a) improving diagnostic messages (a perennial issue), and (b) (semi)
automating error correction. In this case the diagnostic message
is pretty good, except that is doesn't indicate where the IO term
is or where
Simon Raahauge DeSantis wrote:
[...] Here's the snippet in particular (and the results from
evaluation in hbi):
getDirectoryContents "." = filter (\(x:_) - x /= '.');
[65] Cannot unify types:
Prelude.IO
and (Prelude.[])
in (=) (getDirectoryContents ".") (filter (\I -
case I of {
getDirectoryContents "." = filter (\(x:_) - x /= '.');
[65] Cannot unify types:
Prelude.IO
and (Prelude.[])
The problem is that `filter's result type is [a], not
(IO [a]) which its use as an argument to = requires.
The fix is easy: lift its result into the monad (using `return').
This little problem raises two challenges for compiler developers:
(a) improving diagnostic messages (a perennial issue), and (b) (semi)
automating error correction. In this case the diagnostic message
is pretty good, except that is doesn't indicate where the IO term
is or where the [] term is
I'm working on a little toy program in hbc (now that I have a haskell
compiler running I decided to give it a try ;), but I seem to have run into
a monad problem. Here's the snippet in particular (and the results from
evaluation in hbi):
getDirectoryContents "." = filter (\(x:_) - x /= '.');
33 matches
Mail list logo
