Ertugrul Soeylemez wrote:
> There are two issues with unsafePerformIO: [...]
Of course I meant unsafeInterleaveIO, sorry. There are a lot more than
two issues with unsafePerformIO. =)
Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog
Stephen Hicks wrote:
> Magnus Therning wrote:
> > Martijn van Steenbergen wrote:
> >>
> >> Otherwise, you can use unsafeInterleaveIO: no unsafePerformIO or seq
> >> needed, but there's still "unsafe" in that name there. This works for me:
> ...
> > Thanks, that does indeed work, but it still requ
Hello Magnus,
although your approach is a bit more pragmatic, I always prefer to use
concurrency to implement predictable logging. This is a bit more code,
but works much nicer and a lot more predictable:
{-# LANGUAGE ExistentialQuantification #-}
module Main where
import Control.Concurr
Daryoush Mehrtash wrote:
> In category theory functors are defined between two category of C and
> D where every object and morphism from C is mapped to D.
>
> I am trying to make sense of the above definition with functor class
> in Haskell. Let say I am dealing with List type. When I define L
Eugene Kirpichov wrote:
> >> daemon :: IO () -> IO (IO ())
> >> daemon action = do
> >> stopvar <- newIORef False
> >> let run = do
> >> stop <- readIORef stopvar
> >> if stop then return () else (action >> run)
> >> forkIO run
> >> return (writeIORef stopvar T
Daryoush Mehrtash wrote:
> I am trying to figure out if there is a way to model cloud computing
> computations in Haskell.
>
> My specific problems is that in cloud computing, as in Amazon
> WebServices, side effects (writes to storage, simple database, queue)
> follow the eventually consistent m
Luke Palmer wrote:
> On Thu, Jan 22, 2009 at 9:04 AM, Ertugrul Soeylemez wrote:
>
> > Sometimes this is inevitable, but I've never seen a case, where
> > IORefs couldn't be replaced by a more elegant State/StateT-based
> > solution. And if you need to do
Luke Palmer wrote:
> On Thu, Jan 22, 2009 at 5:48 AM, Ertugrul Soeylemez wrote:
>
> > Luke Palmer wrote:
> >
> > > TVars are overkill here, actually, an IORef would be just fine, I
> > > think.
> >
> > Using IORefs is generally a sign of bad sty
Luke Palmer wrote:
> TVars are overkill here, actually, an IORef would be just fine, I
> think.
Using IORefs is generally a sign of bad style. But MVars would
perfectly suffice here. They would be essentially the same, but without
'atomically'.
Greets,
Ertugrul.
--
nightmare = unsafePerfo
David Fox wrote:
> I posted a bug about this
> (http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I had
> to ask here. Using ghc 6.10.1, both readFile "/proc/mounts" and
> Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64
> machine running Linux. Also, Data.ByteS
"Tim Chevalier" wrote:
> Is there a pure Haskell implementation of Floats, i.e., one that
> (unlike GHC.Float) doesn't use foreign calls for things like
> isFloatNegativeZero? I don't care about performance; I'm just looking
> for something that doesn't use foreign calls.
You can easily do it yo
Andrew Coppin wrote:
> Ertugrul Soeylemez wrote:
> > Andrew Coppin wrote:
> >
> >> I would suggest that ExistentiallyQuantifiedTypeVariables would be
> >> an improvement [...]
> >
> > That must be a joke. Typing the long extension names in LANGUAGE
Andrew Coppin wrote:
> I would suggest that ExistentiallyQuantifiedTypeVariables would be an
> improvement [...]
That must be a joke. Typing the long extension names in LANGUAGE
pragmas over and over again is tiring and annoying enough already. We
really don't need even longer names, and your
"Andrew Wagner" wrote:
> I've been playing around with this, but haven't been able to come up
> with anything.
> myFunc f (a,b) (c,d) = (f a c, f b d)
>
> It feels as if there should be a nice simple version of this using
> some combination of {un,}curry, "on", &&&, ***, or something else.
>
> An
"Apfelmus, Heinrich" wrote:
> [...] but this is very different from using a particular monad like
> the state monad and hoping that using it somehow gives an insight into
> the problem domain.
You're right, mostly. However, there are a lot of problems, where you
cannot provide any useful abstra
Jonathan Cast wrote:
> On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira Pinto
> wrote:
>
> > Inspired by the paper "Functional Programming with Overloading and
> > Higher-Order Polymorphism",
> > Mark P Jones
> > (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html)
> >
Ertugrul Soeylemez wrote:
> Personally I prefer this:
>
> somethingWithRandomsM :: (Monad m, Random a) => m a -> Something a
Of course, there is something missing here:
somethingWithRandomsM :: (Monad m, Random a) => m a -> m (Something a)
Sorry.
Greets,
Ertu
"Apfelmus, Heinrich" wrote:
> Ertugrul Soeylemez wrote:
>
> > Let me tell you that usually 90% of my code is monadic and there is
> > really nothing wrong with that. I use especially State monads and
> > StateT transformers very often, because they are c
Hello fellow Haskellers,
When I read questions from Haskell beginners, it somehow seems like they
try to avoid monads and view them as a last resort, if there is no easy
non-monadic way. I'm really sure that the cause for this is that most
tutorials deal with monads very sparingly and mostly in t
"minh thu" wrote:
> Nothing, simply the notation. Now, with the remark of Luke, I'm
> wondering how bad it is to use makeStableName/hashStableName to "copy"
> the data structure in a similar one with explicit reference (that is,
> using pointer or keys in a map or whatever).
Probably you're misu
Adrian Neumann wrote:
> Am 23.12.2008 um 15:16 schrieb Hans van Thiel:
>
> > I just saw somewhere that one of the purposes of monads is to
> > capture side effects. I understand what a side effect is in C, for
> > example. Say you want to switch the contents of two variables. Then
> > you need a
Hans van Thiel wrote:
> On Sat, 2008-12-27 at 02:35 +0100, Ertugrul Soeylemez wrote:
>
> > In the last few weeks I have written a comprehensive tutorial about
> > Haskell monads [1], and I was hoping to get some constructive
> > feedback. I'd appreciate any wel
Ertugrul Soeylemez wrote:
> In the last few weeks I have written a comprehensive tutorial about
> Haskell monads [1], and I was hoping to get some constructive
> feedback. I'd appreciate any well meant criticism.
>
> [1] http://ertes.de/articles/monads.html
Thank you a
Hello fellow Haskellers,
In the last few weeks I have written a comprehensive tutorial about
Haskell monads [1], and I was hoping to get some constructive feedback.
I'd appreciate any well meant criticism.
[1] http://ertes.de/articles/monads.html
Greets,
Ertugrul.
--
nightmare = unsafePerfor
201 - 224 of 224 matches
Mail list logo
