[Haskell-cafe] Re: nhc vs ghc
brad clawsie wrote: can anyone provide a concise list of the major differences between nhc98 and ghc? for example, can i build a cabal package with nhc98? i get that ghc and nhc98 are not interchangeable, otherwise i am not sure The major difference is that nhc98 is pretty much Haskell98 only, so no multi parameter type classes, rank-n-polymorphism or GADTs. It does support existential types, though. In particular, the popular monad transformer library isn't Haskell98, at least concerning the type classes. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call external program and get stdout
Roberto Zunino wrote: Allan Clark wrote: -- Create the process do (_pIn, pOut, pErr, handle) - runInteractiveCommand command -- Wait for the process to finish and store its exit code exitCode - waitForProcess handle Warning: this will get stuck if the command output is so big that it fills the SO buffers. This limit is 64K here. Regards, Zun. Ah thanks for the warning, I've never tested this on anything particularly large. regards allan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: An interesting monad: Prompt
Derek Elkins wrote:
Ryan Ingram wrote:
apfelmus wrote:
A context passing implementation (yielding the ContT monad
transformer)
will remedy this.
Wait, are you saying that if you apply ContT to any monad that has the
left recursion on = takes quadratic time problem, and represent
all primitive operations via lift (never using = within lift),
that you will get a new monad that doesn't have that problem?
If so, that's pretty cool.
To be clear, by ContT I mean this monad:
newtype ContT m a = ContT { runContT :: forall b. (a - m b) - m b }
instance Monad m = Monad (ContT m) where
return x = ContT $ \c - c x
m = f = ContT $ \c - runContT m $ \a - runContT (f a) c
fail = lift . fail
instance MonadTrans ContT where
lift m = ContT $ \c - m = c
evalContT :: Monad m = ContT m a - m a
evalContT m = runContT m return
Yes, that's the case because the only way to use = from the old monad
is via lift. Since only primitive operations are being lifted into the
left of =, it's only nested in a right-associative fashion. The
remaining thing to prove is that ContT itself doesn't have the
left-associativity problem or any other similar problem. It's pretty
intuitive, but unfortunately, I currently don't know how to prove or
even specify that exactly. The problem is that expressions with =
contain arbitrary unapplied lambda abstractions and mixed types but the
types shouldn't be much a minor problem.
Indeed this was discussed on #haskell a few weeks ago. That information
has been put on the wiki at
http://www.haskell.org/haskellwiki/Performance/Monads
and refers to a blog post http://r6.ca/blog/20071028T162529Z.html that
describes it in action.
Note that the crux of the Maybe example on the wiki page is not curing a
left-associativity problem, Maybe doesn't have one. The key point here
is that continuation passing style allows us to inline the liftings
(Just x =) = \f - f x
(Nothing =) = \_ - Nothing
and thus eliminate lots of case analysis. (Btw, this is exactly the
behavior of exceptions in an imperative language.)
(Concerning the blog post, it looks like this inlining brings speed. But
Data.Sequence is not to be underestimated, it may well be responsible
for the meat of the speedup.)
I'm fairly confident, though I'd have to actually work through it, that
the Unimo work, http://web.cecs.pdx.edu/~cklin/ could benefit from
this. In fact, I think this does much of what Unimo does and could
capture many of the same things.
Well, Unimo doesn't have the left-associativity problem in the first
place, so the only motive for using ContT Prompt instead is to
eliminate the Bind constructor and implied case analyses.
But there's a slight yet important difference between Unimo p a and
Unimo' p a = ContT (Prompt p) a , namely the ability the run the
continuation in the outer monad. Let me explain: in the original
Unimo, we have a helper function
observe_monad :: (a - v)
- (forall b . p (Unimo p) b - (b - Unimo p a) - v)
- (Unimo p a - v)
for running a monad. For simplicity and to match with Ryan's prompt,
we'll drop the fact that p can be parametrized on the outer monad,
i.e. we consider
observe_monad :: (a - v)
- (forall b . p b - (b - Unimo p a) - v)
- (Unimo p a - v)
This is just the case expression for the data type
data PromptU p a where
Return :: a - PromptU p a
BindEffect :: p b - (b - Unimo p a) - PromptU p a
observe_monad :: (PromptU p a - v) - (Unimo p a - v)
The difference I'm after is that the second argument to BindEffect is
free to return an Unimo and not only another PromptU! This is quite
handy for writing monads.
In contrast, things for Unimo' p a = ContT (Prompt p) a are as follows:
data Prompt p a where
Return :: a - Prompt p a
BindEffect :: p b - (b - Prompt p a) - Prompt p a
observe :: (Prompt p a - v) - (Unimo' p a - v)
observe f m = f (runCont m Return)
Here, we don't have access to the outer monad Unimo' p a when
defining an argument f to observe. I don't think we can fix that by
allowing the second argument of BindEffect to return an Unimo' p a
since in this case,
lift :: p a - Unimo' p a
lift x = Cont $ BindEffect x
won't work anymore.
Of course, the question now is whether this can be fixed. Put
differently, this is the question I keep asking: does it allow Unimo
to implement strictly more monads than ContT = Unimo' or is the latter
enough? I.e. can every monad be implemented with ContT?
Regards,
apfelmus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: nhc vs ghc
Hi can anyone provide a concise list of the major differences between nhc98 and ghc? for example, can i build a cabal package with nhc98? i get that ghc and nhc98 are not interchangeable, otherwise i am not sure The other major differences: * nhc is unavailable on Windows * nhc programs run much slower * nhc has fewer users and fewer developers, meaning more bugs Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: nhc vs ghc
Hi 1. It IS available on Windows. Not without Mingw/Cygwin - which in my mind makes it not Windows native. I also know that the release is made without testing on Windows, and that certain related tools like hmake rely on shell scripts. If there is someone using nhc seriously on Windows, it would be good if they documented exactly what they needed to do, and ideally supply a binary for the rest of the world. 2. Since it is interpreted, you should compare it with GHCi, not with compiled programs. The comparison is NOT BAD. Really? Do you have a benchmark for that? (sadly nobench is down at the moment) Remember that GHCi does not interpret all code, but actually has massive amounts of it compiled (all the base libraries etc) Also for most users this is an irrelevant distinction. The language shootout does not benchmark Java against GHCi because both use bytecode - they benchmark the speed the user sees at the end. 3. Premises correct, conclusion speculative. Probable, but when you *accuse* somebody, then *prove* it. To take a recent commit message: * Comment out incorrect kind inference. In fact, there is no kind inference at all - just an assignment of kinds to type variables, which turns out to be wrong of course. There are plenty of bugs in nhc. You can't implement the Haskell 98 spec without kind inference, yet nhc (and Yhc) both lack it entirely. There were about 3 changes required to XMonad to make one single module compile with nhc. Not all of these bugs are show stoppers, and its perfectly possible to use it without running into a bug, but there are more out there, and its more likely you'll run across one. (who has nothing to do with nhc, but who respects enormously this effort) I also respect this effort as well! We need more compilers, and not just toy compilers, but production compilers! Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: Best Linux for Haskell?
Martin DeMello wrote: On 11/6/07, Maurício [EMAIL PROTECTED] wrote: Maybe (and only maybe), before choosing a distribution, you should choose a package system, since that's what you are going to use to install software. Look for RPM and APT, and see what you think. With my package system (I don't wanna give you any prejudice, so I won't tell you it's APT), I can get upgrades easily. But that's because I know how to use it. There are also other options beside RPM and APT. Gentoo's portage (inspired by FreeBSD's ports) is the best linux packaging system I've come across, but I wouldn't recommend Gentoo itself as a first distro. It makes a brilliant second one, though. Even better, at least in theory, is Nix (http://nix.cs.uu.nl/index.html). Unfortunately it is not yet mature. And of course nobody uses it (yet ;-) BTW, Nix is based on a purely functional package description language which is also maximally lazy, meaning that syntactically equal terms are /always/ shared and only evaluated once. (And yes, it is of course turing complete.) Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call external program and get stdout
dons did a blog post about a shell monad which I think does what you ask. http://cgi.cse.unsw.edu.au/~dons/blog/2007/03 very nice, I use it myself. t. 2007/11/22, Maurício [EMAIL PROTECTED]: Hi, How can I call a program (like, for instance, 'grep text *') and get the standard output? All actions I found (executeFile, system) do not give me the output of the program. Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] is there a more concise way to generate helper functions for a datatype built on records?
I think I'm running into more or less the same issue discussed at
http://bloggablea.wordpress.com/2007/04/24/haskell-records-considered-grungy/
Just wondering if I missed anything, or if any of the ideas
considering better records setter/getters have been implemented in the
meantime.
t.
**
-- Is there any way to do the following more concisely?
-- Seems like a lot of boilerplate
data GameState = GameState { guesses :: Int, userHighScores ::
UserHighScores, answer :: Maybe Int }
deriving Show
-- State Helpers ---
modGuesses f gSt = _set_guesses ( (f . guesses) gSt) gSt
modUserHighScores f gSt = _set_userHighScores ( (f . userHighScores) gSt) gSt
modAnswer f gSt = _set_answer ( (f . answer) gSt) gSt
_set_guesses new gSt = gSt {guesses=new}
_set_userHighScores new gSt = gSt { userHighScores=new }
_set_answer new gSt = gSt { answer=new }
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is there a more concise way to generate helper functions for a datatype built on records?
Hi
Some of these can be automatically derived by the Data.Derive tool. If
you want any more, then submit a patch and they can all be derived.
http://www-users.cs.york.ac.uk/~ndm/derive/
The derivations Set, Is, From, Has, LazySet all look useful. A bit
more documentation on what each one does would also be handy, if
anyone wants to write it!
Thanks
Neil
On Nov 24, 2007 4:01 PM, Thomas Hartman [EMAIL PROTECTED] wrote:
I think I'm running into more or less the same issue discussed at
http://bloggablea.wordpress.com/2007/04/24/haskell-records-considered-grungy/
Just wondering if I missed anything, or if any of the ideas
considering better records setter/getters have been implemented in the
meantime.
t.
**
-- Is there any way to do the following more concisely?
-- Seems like a lot of boilerplate
data GameState = GameState { guesses :: Int, userHighScores ::
UserHighScores, answer :: Maybe Int }
deriving Show
-- State Helpers ---
modGuesses f gSt = _set_guesses ( (f . guesses) gSt) gSt
modUserHighScores f gSt = _set_userHighScores ( (f . userHighScores) gSt) gSt
modAnswer f gSt = _set_answer ( (f . answer) gSt) gSt
_set_guesses new gSt = gSt {guesses=new}
_set_userHighScores new gSt = gSt { userHighScores=new }
_set_answer new gSt = gSt { answer=new }
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: nhc vs ghc
On Sat, Nov 24, 2007 at 10:44:45AM +, Neil Mitchell wrote: Hi can anyone provide a concise list of the major differences between nhc98 and ghc? for example, can i build a cabal package with nhc98? i get that ghc and nhc98 are not interchangeable, otherwise i am not sure The other major differences: * nhc is unavailable on Windows * nhc programs run much slower * nhc has fewer users and fewer developers, meaning more bugs There are also a few advantages: * It was written on an Acorn A4000, an 80s-era PC with a whopping 3MB of memory; as such it is much more memory-friendly than GHC, which at the time wanted 16MB for normal use. * It's unrelated to GHC, which means that the set of bugs are uncorrelated. If you think GHC is doing something wrong, ask NHC for a second opinion. * It's much easier to port than GHC. (And an important disadvantage - The original author of NHC, Niklaus Röjemo, has disappeared off the face of the Internet, and the acting maintainer doesn't actually grok most of the code.) Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An interesting monad: Prompt
Looks very cool. So I tried playing with this code, unfortunately
couldn't get it to compile.
Could you double check that what you posted compiles, and if it does,
any idea what I'm doing wrong?
This is with
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
thanks, t.
Prelude :r
[1 of 1] Compiling Prompt ( prompt.lhs, interpreted )
prompt.lhs:140:1:
Could not deduce (Monad tm)
from the context (Monad (t m), MonadTrans t, MonadPrompt p m)
arising from the superclasses of an instance declaration
at prompt.lhs:140:1
Possible fix:
add (Monad tm) to the instance declaration superclass context
In the instance declaration for `MonadPrompt p tm'
prompt.lhs:141:13:
Couldn't match expected type `tm' (a rigid variable)
against inferred type `t1 m1'
`tm' is bound by the instance declaration at prompt.lhs:140:1
Expected type: p a - tm a
Inferred type: p a - t1 m1 a
In the expression: lift . prompt
In the definition of `prompt': prompt = lift . prompt
Failed, modules loaded: none.
This is around
-- Just for fun, make it work with StateT as well
-- (needs -fallow-undecidable-instances)
instance (Monad (t m), MonadTrans t, MonadPrompt p m) = MonadPrompt p (tm)
where
prompt = lift . prompt
2007/11/18, Ryan Ingram [EMAIL PROTECTED]:
(This message is a literate haskell file. Code for the Prompt monad is
preceded by ; code for my examples is preceded by ] and isn't complete,
but intended for illustration.)
I've been trying to implement a few rules-driven board/card games in Haskell
and I always run into the ugly problem of how do I get user input?
The usual technique is to embed the game in the IO Monad:
] type Game = IO
] -- or
] type Game = StateT GameState IO
The problem with this approach is that now arbitrary IO computations are
expressible as part of a game action, which makes it much harder to
implement
things like replay, undo, and especially testing!
The goal was to be able to write code like this:
] takeTurn :: Player - Game ()
] takeTurn player = do
] piece - action (ChoosePiece player)
] attack - action (ChooseAttack player piece)
] bonusTurn - executeAttack piece attack
] when bonusTurn $ takeTurn player
but be able to script the code for testing, allow undo, automatically
be able to save replays, etc.
While thinking about this problem earlier this week, I came up with the
following solution:
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances
#-}
-- undecidable instances is only needed for the MonadTrans instance below
module Prompt where
import Control.Monad.Trans
import Control.Monad.Identity
class Monad m = MonadPrompt p m | m - p where
prompt :: p a - m a
prompt is an action that takes a prompt type and gives you a result.
A simple example:
] prompt [1,3,5] :: MonadPrompt [] m = m Int
This prompt would ask for someone to pick a value from the list and return
it.
This would be somewhat useful on its own; you could implement a choose
function that picked randomly from a list of options and gave
non-deterministic (or even exhaustive) testing, but on its own this wouldn't
be much better than the list monad.
What really made this click for me was that the prompt type could be built
on a GADT:
] newtype GamePrompt a = GP (GameState, GameChoice a)
] data GameChoice a where
]-- pick a piece to act with
]ChoosePiece :: Player - GameChoice GamePiece
]-- pick how they should attack
]ChooseAttack :: Player - GamePiece - GameChoice AttackType
]-- etc.
Now you can use this type information as part of a handler function:
] gameIO :: GamePrompt a - IO a
] gameIO (GP (state, ChoosePiece player)) = getPiece state player
] gameIO (GP (state, ChooseAttack player piece)) = attackMenu player piece
] -- ...
The neat thing here is that the GADT specializes the type of IO a on the
right hand side. So, getPiece state player has the type IO GamePiece,
not
the general IO a. So the GADT is serving as a witness of the type of
response wanted by the game.
Another neat things is that, you don't need to embed this in the IO monad at
all; you could instead run a pure computation to do AI, or even use it for
unit testing!
-- unit testing example
data ScriptElem p where SE :: p a - a - ScriptElem p
type Script p = [ScriptElem p]
infix 1 --
(--) = SE
] gameScript :: ScriptElem GameChoice - GameChoice a - Maybe a
] gameScript (SE (ChoosePiece _)piece) (ChoosePiece _)= Just piece
] gameScript (SE (ChooseAttack _ _) attack) (ChooseAttack _ _) = Just attack
] gameScript _ _
= Nothing
]
] testGame :: Script GameChoice
] testGame =
] [ ChoosePiece P1-- Knight
] , ChooseAttack P1 Knight -- Charge
] , ChoosePiece P2-- FootSoldier
] , ...
] ]
So, how to implement all of this?
data Prompt (p
Re: [Haskell-cafe] An interesting monad: Prompt
fwiw, if I comment those two lines around 141 out, it compiles.
t.
2007/11/24, Thomas Hartman [EMAIL PROTECTED]:
Looks very cool. So I tried playing with this code, unfortunately
couldn't get it to compile.
Could you double check that what you posted compiles, and if it does,
any idea what I'm doing wrong?
This is with
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
thanks, t.
Prelude :r
[1 of 1] Compiling Prompt ( prompt.lhs, interpreted )
prompt.lhs:140:1:
Could not deduce (Monad tm)
from the context (Monad (t m), MonadTrans t, MonadPrompt p m)
arising from the superclasses of an instance declaration
at prompt.lhs:140:1
Possible fix:
add (Monad tm) to the instance declaration superclass context
In the instance declaration for `MonadPrompt p tm'
prompt.lhs:141:13:
Couldn't match expected type `tm' (a rigid variable)
against inferred type `t1 m1'
`tm' is bound by the instance declaration at prompt.lhs:140:1
Expected type: p a - tm a
Inferred type: p a - t1 m1 a
In the expression: lift . prompt
In the definition of `prompt': prompt = lift . prompt
Failed, modules loaded: none.
This is around
-- Just for fun, make it work with StateT as well
-- (needs -fallow-undecidable-instances)
instance (Monad (t m), MonadTrans t, MonadPrompt p m) = MonadPrompt p (tm)
where
prompt = lift . prompt
2007/11/18, Ryan Ingram [EMAIL PROTECTED]:
(This message is a literate haskell file. Code for the Prompt monad is
preceded by ; code for my examples is preceded by ] and isn't complete,
but intended for illustration.)
I've been trying to implement a few rules-driven board/card games in Haskell
and I always run into the ugly problem of how do I get user input?
The usual technique is to embed the game in the IO Monad:
] type Game = IO
] -- or
] type Game = StateT GameState IO
The problem with this approach is that now arbitrary IO computations are
expressible as part of a game action, which makes it much harder to
implement
things like replay, undo, and especially testing!
The goal was to be able to write code like this:
] takeTurn :: Player - Game ()
] takeTurn player = do
] piece - action (ChoosePiece player)
] attack - action (ChooseAttack player piece)
] bonusTurn - executeAttack piece attack
] when bonusTurn $ takeTurn player
but be able to script the code for testing, allow undo, automatically
be able to save replays, etc.
While thinking about this problem earlier this week, I came up with the
following solution:
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances
#-}
-- undecidable instances is only needed for the MonadTrans instance below
module Prompt where
import Control.Monad.Trans
import Control.Monad.Identity
class Monad m = MonadPrompt p m | m - p where
prompt :: p a - m a
prompt is an action that takes a prompt type and gives you a result.
A simple example:
] prompt [1,3,5] :: MonadPrompt [] m = m Int
This prompt would ask for someone to pick a value from the list and return
it.
This would be somewhat useful on its own; you could implement a choose
function that picked randomly from a list of options and gave
non-deterministic (or even exhaustive) testing, but on its own this wouldn't
be much better than the list monad.
What really made this click for me was that the prompt type could be built
on a GADT:
] newtype GamePrompt a = GP (GameState, GameChoice a)
] data GameChoice a where
]-- pick a piece to act with
]ChoosePiece :: Player - GameChoice GamePiece
]-- pick how they should attack
]ChooseAttack :: Player - GamePiece - GameChoice AttackType
]-- etc.
Now you can use this type information as part of a handler function:
] gameIO :: GamePrompt a - IO a
] gameIO (GP (state, ChoosePiece player)) = getPiece state player
] gameIO (GP (state, ChooseAttack player piece)) = attackMenu player piece
] -- ...
The neat thing here is that the GADT specializes the type of IO a on the
right hand side. So, getPiece state player has the type IO GamePiece,
not
the general IO a. So the GADT is serving as a witness of the type of
response wanted by the game.
Another neat things is that, you don't need to embed this in the IO monad at
all; you could instead run a pure computation to do AI, or even use it for
unit testing!
-- unit testing example
data ScriptElem p where SE :: p a - a - ScriptElem p
type Script p = [ScriptElem p]
infix 1 --
(--) = SE
] gameScript :: ScriptElem GameChoice - GameChoice a - Maybe a
] gameScript (SE (ChoosePiece _)piece) (ChoosePiece _)= Just piece
] gameScript (SE (ChooseAttack _ _) attack) (ChooseAttack _ _) = Just attack
] gameScript _ _
= Nothing
]
Re: [Haskell-cafe] An interesting monad: Prompt
-- Just for fun, make it work with StateT as well -- (needs -fallow-undecidable-instances) instance (Monad (t m), MonadTrans t, MonadPrompt p m) = MonadPrompt p (tm) where prompt = lift . prompt Looks like that should be MonadPrompt p (t m) rather than (tm). Note the space. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An interesting monad: Prompt
that did it, thanks. 2007/11/24, Brent Yorgey [EMAIL PROTECTED]: -- Just for fun, make it work with StateT as well -- (needs -fallow-undecidable-instances) instance (Monad (t m), MonadTrans t, MonadPrompt p m) = MonadPrompt p (tm) where prompt = lift . prompt Looks like that should be MonadPrompt p (t m) rather than (tm). Note the space. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: An interesting monad: Prompt
On Sat, 2007-11-24 at 11:10 +0100, apfelmus wrote:
Derek Elkins wrote:
Ryan Ingram wrote:
apfelmus wrote:
A context passing implementation (yielding the ContT monad
transformer)
will remedy this.
Wait, are you saying that if you apply ContT to any monad that has the
left recursion on = takes quadratic time problem, and represent
all primitive operations via lift (never using = within lift),
that you will get a new monad that doesn't have that problem?
If so, that's pretty cool.
To be clear, by ContT I mean this monad:
newtype ContT m a = ContT { runContT :: forall b. (a - m b) - m b }
instance Monad m = Monad (ContT m) where
return x = ContT $ \c - c x
m = f = ContT $ \c - runContT m $ \a - runContT (f a) c
fail = lift . fail
instance MonadTrans ContT where
lift m = ContT $ \c - m = c
evalContT :: Monad m = ContT m a - m a
evalContT m = runContT m return
Yes, that's the case because the only way to use = from the old monad
is via lift. Since only primitive operations are being lifted into the
left of =, it's only nested in a right-associative fashion. The
remaining thing to prove is that ContT itself doesn't have the
left-associativity problem or any other similar problem. It's pretty
intuitive, but unfortunately, I currently don't know how to prove or
even specify that exactly. The problem is that expressions with =
contain arbitrary unapplied lambda abstractions and mixed types but the
types shouldn't be much a minor problem.
Indeed this was discussed on #haskell a few weeks ago. That information
has been put on the wiki at
http://www.haskell.org/haskellwiki/Performance/Monads
and refers to a blog post http://r6.ca/blog/20071028T162529Z.html that
describes it in action.
Note that the crux of the Maybe example on the wiki page is not curing a
left-associativity problem, Maybe doesn't have one.
I agree, hence the fact that that is massively understated. However,
while Maybe may not have a problem on the same order, there is
definitely a potential inefficiency.
(Nothing = f) = g expands to
case (case Nothing of Nothing - Nothing; Just x - f x) of
Nothing - Nothing
Just y - g y
This tests that original Nothing twice. This can be arbitrarily deep.
The right associative version would expand to
case Nothing of
Nothing - Nothing
Just x - f x = g
The key point here
is that continuation passing style allows us to inline the liftings
(Just x =) = \f - f x
(Nothing =) = \_ - Nothing
and thus eliminate lots of case analysis. (Btw, this is exactly the
behavior of exceptions in an imperative language.)
Indeed, avoiding case analyses and achieving exactly the behaviour of
exceptions was the motivation.
(Concerning the blog post, it looks like this inlining brings speed. But
Data.Sequence is not to be underestimated, it may well be responsible
for the meat of the speedup.)
I'm not quite sure what all is being compared to what, but Russell
O'Connor did say that using continuations passing style did lead to a
significant percentage speed up.
I'm fairly confident, though I'd have to actually work through it, that
the Unimo work, http://web.cecs.pdx.edu/~cklin/ could benefit from
this. In fact, I think this does much of what Unimo does and could
capture many of the same things.
Well, Unimo doesn't have the left-associativity problem in the first
place, so the only motive for using ContT Prompt instead is to
eliminate the Bind constructor and implied case analyses.
But there's a slight yet important difference between Unimo p a and
Unimo' p a = ContT (Prompt p) a , namely the ability the run the
continuation in the outer monad. Let me explain: in the original
Unimo, we have a helper function
observe_monad :: (a - v)
- (forall b . p (Unimo p) b - (b - Unimo p a) - v)
- (Unimo p a - v)
for running a monad. For simplicity and to match with Ryan's prompt,
we'll drop the fact that p can be parametrized on the outer monad,
i.e. we consider
observe_monad :: (a - v)
- (forall b . p b - (b - Unimo p a) - v)
- (Unimo p a - v)
This is just the case expression for the data type
data PromptU p a where
Return :: a - PromptU p a
BindEffect :: p b - (b - Unimo p a) - PromptU p a
observe_monad :: (PromptU p a - v) - (Unimo p a - v)
The difference I'm after is that the second argument to BindEffect is
free to return an Unimo and not only another PromptU! This is quite
handy for writing monads.
In contrast, things for Unimo' p a = ContT (Prompt p) a are as follows:
data Prompt p a where
Return :: a - Prompt p a
BindEffect :: p b - (b - Prompt p a) - Prompt p a
observe :: (Prompt p a - v) - (Unimo' p a - v)
observe f m = f (runCont m Return)
Re: [Yhc] Re: [Haskell-cafe] yhc install fails
Thanks, that worked. I think there's some weird issue with the way the build happens that requires you to do rm -rf yhc; darccs get http://...yhc for a truly fair build to take place. I saw something in a bug report about how things get cached. That means that an ok from a buildbot doesn't mean that the build is really ok. It occurs to me that if it's possible to get the buildbot to do rm -rf and darcs re-checkout that might be worth doing, until the issues with stuff getting cached get resolved. But maybe that's smiting a mosquito with a flamethrower. thomas. 2007/11/22, Thomas Shackell [EMAIL PROTECTED]: Apologies, I broke this when I fixed the getArgs bug. It's actually just a build problem, Storable needs to be built before C/String. I didn't notice it because it only happens with a fresh (uncompiled) copy of yhc. Anyway fix pushed. Thanks Tom Neil Mitchell wrote: Yhc people: On Nov 21, 2007 8:46 PM, Thomas Hartman [EMAIL PROTECTED] wrote: I'm having the devil of a time getting yhc to install. http://hpaste.org/4028 or for posterity [EMAIL PROTECTED]:~/yhc-install/yhcscons ... blah blah blah... Compiling PreludeAux ( src/packages/yhc-base-1.0/PreludeAux.hs ) YHC_build([src/packages/yhc-base-1.0/Foreign/Util.hbc], [src/packages/yhc-base-1.0/Foreign/Util.hs]) inst/bin/yhc --core --cpp -c src/packages/yhc-base-1.0/Foreign/Util.hs Compiling Foreign.Util ( src/packages/yhc-base-1.0/Foreign/Util.hs ) YHC_build([src/packages/yhc-base-1.0/Foreign/C/String.hbc], [src/packages/yhc-base-1.0/Foreign/C/String.hs]) inst/bin/yhc --core --cpp -c src/packages/yhc-base-1.0/Foreign/C/String.hs Error: File not found, Foreign.Storable Reason: imported from Foreign.C.String Looked in: /root/yhc-install/yhc/src/packages/yhc-base-1.0/ /root/yhc-install/yhc/inst/lib/yhc/packages/yhc-base/1.0 scons: *** [src/packages/yhc-base-1.0/Foreign/C/String.hbc] Error 1 scons: building terminated because of errors. [EMAIL PROTECTED]:~/yhc-install/yhcghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.1 advice? thomas. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Yhc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/yhc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] problems building ycr2js
OK, I struggled through the instructions at
http://haskell.org/haskellwiki/Yhc/Javascript/Users_guide#Downloading
and am getting tripped up at
(cd src/translator/js; make all install)
any advice?
... blah blah blah
ghc --make -i../../../depends/filepath splitter.hs -o
/home/thartman/haskell-installs/yhc-install/yhc/src/translator/js/inst\
/bin/splitter
[1 of 4] Compiling System.FilePath.Version_0_11 (
../../../depends/filepath/System/FilePath/Version_0_11.hs,
../../../depend\
s/filepath/System/FilePath/Version_0_11.o )
[2 of 4] Compiling System.FilePath (
../../../depends/filepath/System/FilePath.hs,
../../../depends/filepath/System/FilePat\
h.o )
[4 of 4] Compiling Main ( splitter.hs, splitter.o )
Linking
/home/thartman/haskell-installs/yhc-install/yhc/src/translator/js/inst/bin/splitter
...
echo W3C/addtags.idl
for tag in SUB SUP SPAN BDO I B U S \
STRIKE BIG SMALL EM STRONG DFN CODE \
SAMP KBD VAR CITE ACRONYM ABBR \
DD DT NOFRAMES NOSCRIPT ADDRESS CENTER ; do \
ltag=`echo ${tag:1} | tr [:upper:] [:lower:]` ; \
echo interface HTML${tag:0:1}${ltag}Element
: HTMLElement { W3C/addtags.idl ; \
echo }; W3C/addtags.idl ; \
echo W3C/addtags.idl ; \
done
/bin/sh: Syntax error: Bad substitution
make: *** [W3C/addtags.idl] Error 2
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] nhc vs ghc
On Fri, 2007-11-23 at 23:33 -0800, brad clawsie wrote: for example, can i build a cabal package with nhc98? As of yesterday the answer is yes! (probably) :-) I'm glad you asked about building and not installing since the answer to that question would be no. Support in Cabal for building with nhc98 and hmake was added yesterday. I expect support for installing will be added soon. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] been scouring through the Haskell prelude to no avail ...
Hello, Is there any predefined datatype that can be used to represent a two byte value? Kind regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] been scouring through the Haskell prelude to no avail ...
Word16 from the Data.Word module. Luke On Nov 24, 2007 11:47 PM, Galchin Vasili [EMAIL PROTECTED] wrote: Hello, Is there any predefined datatype that can be used to represent a two byte value? Kind regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is there a more concise way to generate helper functions for a datatype built on records?
There is a simplified version of HList style functionality inside HAppS-Data because I found Oleg's repo too hard to understand. -Alex- Stuart Cook wrote: On 11/25/07, Thomas Hartman [EMAIL PROTECTED] wrote: I think I'm running into more or less the same issue discussed at http://bloggablea.wordpress.com/2007/04/24/haskell-records-considered-grungy/ Just wondering if I missed anything, or if any of the ideas considering better records setter/getters have been implemented in the meantime. Have a look at [http://code.haskell.org/category], and the associated blog posts http://twan.home.fmf.nl/blog/haskell/overloading-functional-references.details (http://tinyurl.com/2ustba) and http://twan.home.fmf.nl/blog/haskell/References-Arrows-and-Categories.details (http://tinyurl.com/2v8het) which discuss functional references (similar to Luke's), and include Template Haskell code for deriving more flexible accessors from a record declaration. Also check out HList [http://homepages.cwi.nl/~ralf/HList/], which can do some interesting things, provided you're willing to abandon the built-in record system. Stuart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] emacs haskellers: r-stripping files becomes popular
why care about trailing whitespace? On Nov 16, 2007 8:14 AM, Valery V. Vorotyntsev [EMAIL PROTECTED] wrote: Add the following lines to your ~/.emacs: --- BEGIN OF ELISP CODE --- ;(global-set-key (kbd f9 s) 'delete-trailing-whitespace) (defun delete-trailing-whitespace-if-confirmed () Delete all the trailing whitespace across the current buffer, asking user for confirmation. (if (and (save-excursion (goto-char (point-min)) (re-search-forward [[:space:]]$ nil t)) (y-or-n-p Delete trailing whitespace? )) (delete-trailing-whitespace))) (add-hook 'before-save-hook 'delete-trailing-whitespace-if-confirmed) --- END OF ELISP CODE --- Have fun! -- vvv ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] emacs haskellers: r-stripping files becomes popular
On Nov 24, 2007 10:55 PM, Conal Elliott [EMAIL PROTECTED] wrote: why care about trailing whitespace? Probably because it looks bad in darcs patch summaries (trailing whitespace -- little red dollar signs). Unless there's another reason I don't know about. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] emacs haskellers: r-stripping files becomes popular
On 24 Nov 2007, at 9:09 PM, Brent Yorgey wrote: On Nov 24, 2007 10:55 PM, Conal Elliott [EMAIL PROTECTED] wrote: why care about trailing whitespace? Probably because it looks bad in darcs patch summaries (trailing whitespace -- little red dollar signs). Unless there's another reason I don't know about. It breaks C-e. (Irreparably, of course). jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pretty-printing peg solitaire boards
Hi, I'm trying to pretty-print (with Text . PrettyPrint . HughesPJ) a set of peg solitaire boards. No matter what I try, I always get this: 00# 00# #00 000 000 000 000 : 00# 00# 000 000 000 000 000 but what I really want is this: 00# 00# 00# 00# #00 000 000 : 000 000 000 000 000 000 000 What I'm I doing wrong? When I have two boards a,b::Doc, I'm composing them with a + colon + b and rendering them with just 'render'. Should I try something else? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pretty-printing peg solitaire boards
On Sun, Nov 25, 2007 at 03:40:26AM -0200, Maurício wrote: Hi, I'm trying to pretty-print (with Text . PrettyPrint . HughesPJ) a set of peg solitaire boards. No matter what I try, I always get this: 00# 00# #00 000 000 000 000 : 00# 00# 000 000 000 000 000 but what I really want is this: 00# 00# 00# 00# #00 000 000 : 000 000 000 000 000 000 000 What I'm I doing wrong? When I have two boards a,b::Doc, I'm composing them with a + colon + b and rendering them with just 'render'. Should I try something else? Right; Text.PrettyPrint is designed for rendering code, where there is a natural 1D structure. For instance, stmt semi does the right thing for code - sticking the semicolon at the very end. For text graphics you want to do something else... Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pretty-printing peg solitaire boards
On 25/11/2007, Maurício [EMAIL PROTECTED] wrote: Hi, I'm trying to pretty-print (with Text . PrettyPrint . HughesPJ) a set of peg solitaire boards. No matter what I try, I always get this: 00# 00# #00 000 000 000 000 : 00# 00# 000 000 000 000 000 Just curious. Are you working on the algorithm also? :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
