[Haskell-cafe] Haskell Weekly News: Issue 210
Welcome to issue 210 of the HWN, a newsletter covering developments in
the Haskell community. This release covers the week of November 27 to
December 3, 2011.
You can find the HTML version at:
http://contemplatecode.blogspot.com/2011/12/haskell-weekly-news-issue-210.html
Announcements
Heinrich Hordegen announced a tentative 2012 meeting schedule for
Munich Haskell group.
[1] http://goo.gl/JrnP6
New and Updated Projects
* data-timeout (Mikhail Vorozhtsov) Allows one to specify time
units for timeouts and convert between them.
[2] http://goo.gl/fbfGM
* Netwire (Ertugrul Soylemez; 3.0.0) Major API change.
[3] http://goo.gl/8hPwS
* monad-control (Bas van Dijk; 0.3) New and improved API.
[4] http://goo.gl/so3s9
Quotes of the Week
* Jafet: They're not nasty; their niceness is just distributed over
more people
* copumpkin: U NEED MOANAD
* xplat: i have a feeling that trying to write an interesting
dependently-typed program in Shen at any time in the near future
would be like trying to host a holiday dinner starting with an
empty lot, 2x4s, a stack of window panes, some cables and wiring
boxes, sheets of drywall, disconnected appliances, roof shingles,
rolls of insulation and bags of concrete
* Axman6: {-# PRAGMA ThisShitNeedsMoarFast #-}
Top Reddit Stories
* Name Your Type Variables!
Domain: amateurtopologist.com, Score: 71, Comments: 38
On Reddit: [5] http://goo.gl/I2uny
Original: [6] http://goo.gl/yRbmO
* Insane Haskell Professor on Lambda Calculus. Wait for it...
Domain: youtube.com, Score: 66, Comments: 17
On Reddit: [7] http://goo.gl/uDQJS
Original: [8] http://goo.gl/IauHk
* criterion 0.6 produces shiny new performance reports
Domain: bos.github.com, Score: 63, Comments: 8
On Reddit: [9] http://goo.gl/F2K76
Original: [10] http://goo.gl/x720h
* [commit: base] master: Add traceStack :: String -> a -> a
Domain: haskell.org, Score: 48, Comments: 5
On Reddit: [11] http://goo.gl/HCbf2
Original: [12] http://goo.gl/JzO3O
* Elm: functional reactive web-programming (compiles to html, css, js).
Just added reactive values, basic canvas support, and new interactive
examples.
Domain: elm-lang.org, Score: 45, Comments: 19
On Reddit: [13] http://goo.gl/mKS9a
Original: [14] http://goo.gl/ASt27
* Snap 0.7 released
Domain: snapframework.com, Score: 41, Comments: 1
On Reddit: [15] http://goo.gl/R3A8Y
Original: [16] http://goo.gl/SVgXy
* Haskell Communities and Activities Report - November 2011 edition
Domain: haskell.org, Score: 35, Comments: 0
On Reddit: [17] http://goo.gl/X82AK
Original: [18] http://goo.gl/CGKAr
* "fix' f = f (fix' f)" vs. "fix f = let x = f x in x"
Domain: groups.google.com, Score: 33, Comments: 15
On Reddit: [19] http://goo.gl/vadtO
Original: [20] http://goo.gl/SQSFL
* Announcing cabal-src: solve (some of) cabal dependency hell
Domain: yesodweb.com, Score: 32, Comments: 15
On Reddit: [21] http://goo.gl/PIB4S
Original: [22] http://goo.gl/00LZz
* aeson 0.4: easier, faster, nicer
Domain: github.com, Score: 31, Comments: 18
On Reddit: [23] http://goo.gl/G1J5A
Original: [24] http://goo.gl/DQ4bc
* Package authors: Please use Packdeps!
Domain: yesodweb.com, Score: 24, Comments: 10
On Reddit: [25] http://goo.gl/bLYvt
Original: [26] http://goo.gl/fNh9n
* Slides from my guest lecture at Stanford
Domain: blog.johantibell.com, Score: 22, Comments: 14
On Reddit: [27] http://goo.gl/ITFkN
Original: [28] http://goo.gl/4w1tK
Top StackOverflow Questions
* How to write a Haskell function that takes a variadic function as an
argument
votes: 28, answers: 1
Read on SO: [29] http://goo.gl/JqZ3H
* Functional lenses
votes: 18, answers: 2
Read on SO: [30] http://goo.gl/Qn2Ff
* Haskell : An example of a Foldable which is not a Functor?
votes: 17, answers: 2
Read on SO: [31] http://goo.gl/42lSo
* How does IncoherentInstances work?
votes: 17, answers: 1
Read on SO: [32] http://goo.gl/O1Ha4
* Minimum specification for Haskell library type classes?
votes: 16, answers: 2
Read on SO: [33] http://goo.gl/L7mO6
* Expressive and composable error types
votes: 16, answers: 1
Read on SO: [34] http://goo.gl/vkoZb
* Distributed Haskell state of the art in 2011?
votes: 16, answers: 2
Read on SO: [35] http://goo.gl/mx0kd
* Is it possible to implement liftM2 in Scala?
votes: 15, answers: 1
Read on SO: [36] http://goo.gl/p6TDl
* Are Haskell FlexibleInstances a stable extension to the language?
votes: 15, answers: 1
Read on SO: [37] http://goo.gl/sQc37
* Is Milner let polymorphism a rank 2 feature?
votes: 13, answers: 4
Read on SO: [38] http://goo.gl/kOcnW
Until next time,
Daniel Santa Cruz
Referen
Re: [Haskell-cafe] Why doesn't this work? (palindrome :: IO)
On Wed, Dec 7, 2011 at 23:24, Alexej Segeda wrote: > case s of >(s == reverse s)-> putStrLn (s ++ " is a > palindrome") >otherwise -> putStrLn (s ++ " is not a > palindrome") > case does pattern matching, not Boolean expressions. (s == reverse s) is not a useful pattern, and in fact is probably a syntax error because == is not a valid infix constructor. If you want to do Boolean comparisons in a case, you need to use something like > case () of > () | s == reverse s -> putStrLn "palindrome" > _ -> putStrLn "nope" (otherwise isn't doing what you think there, either; it's exactly equivalent to the _ (unnamed placeholder) I used, since you aren't then using otherwise as the local binding (shadowing the Prelude one) that it is.) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why doesn't this work? (palindrome :: IO)
Hi! A couple of months ago, I wrote an exam in an introductory Haskell course and failed, all because of an assignment that I was convinced would work, but for some reason, it didn't. The assignment was to write a function that would take a line, then determine whether it's a palindrome or not. My code follows: palindrome :: IO () palindrome = do putStr "Type in a word" s <- getLine case s of (s == reverse s)-> putStrLn (s ++ " is a palindrome") otherwise -> putStrLn (s ++ " is not a palindrome") The interesting thing is, that if I change the "case ... of" statement to an "if ... then ... else" statement, this magically starts to work. Since I no longer am enrolled (I have to take the course next year), I can't ask a teacher, but my curiosity still bugs me. Why doesn't this work? And why does it work with a "if ... then ...else" statement? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
On Wed, Dec 7, 2011 at 20:35, Jason Dagit wrote: > > They *do* terminate; a zombie is a dead process waiting for its parent to > > reap it with waitForProcess. There's also some POSIX stuff you can do to > > have them auto-reaped, but doing that correctly and portably is somewhat > > painful. > > You can use a double fork to make this portable and not painful. It's > just that you have to fork twice, which can be expensive in some > cases. > And problematic if you're using a pipe to communicate with the child, which seemed quite possible. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
On Wed, Dec 7, 2011 at 7:19 AM, Brandon Allbery wrote: > On Wed, Dec 7, 2011 at 06:47, Dan Rosén wrote: >> >> I'm using Haskell to run a lot of instances of an Automated Thorem Prover, >> eprover. I have pasted a smaller version of my program at >> http://hpaste.org/54954. It runs eprover sequentially on all input files, >> with a timeout of 100ms. Unfortunately, it leaves a lot of zombie processes >> around, probably due to the fact that terminateProcess fails to terminate >> them, even though eprover terminates on SIGTERM. > > > They *do* terminate; a zombie is a dead process waiting for its parent to > reap it with waitForProcess. There's also some POSIX stuff you can do to > have them auto-reaped, but doing that correctly and portably is somewhat > painful. You can use a double fork to make this portable and not painful. It's just that you have to fork twice, which can be expensive in some cases. Explanation here: http://stackoverflow.com/a/881434/5113 Here is a Haskell example from xmonad: http://hackage.haskell.org/packages/archive/xmonad/0.7/doc/html/src/XMonad-Core.html#doubleFork If you're planning to send a SIGTERM later, then double forking may make that harder as I think you'd have to communicate the PID up one level. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
Thank you very much for your answers. Felipe's suggestion to use waitForProcess after terminateProcess did the trick. No more zombies around :) Best regards, Dan Rosén On Wed, Dec 7, 2011 at 4:39 PM, Donn Cave wrote: > Quoth Felipe Almeida Lessa , > > On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery > wrote: > >> They *do* terminate; a zombie is a dead process waiting for its parent > to > >> reap it with waitForProcess. There's also some POSIX stuff you can do > to > >> have them auto-reaped, but doing that correctly and portably is somewhat > >> painful. > > > > But zombie processes do consume a row in the process table, right? If > > so, then it's bad to have them around. > > Correct. As noted above, clean up with waitForProcess to release this > resource. If it's more convenient, that could be done up front, by > forking twice and waiting for the intermediate process. One possibly > convenient way to do that might be something like runCommand "eprover &". > >Donn > > ___ > 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] How did iteratees get their names?
Henrik Nilsson writes: >> Just like chatter and chattee, employer and employee, there is an >> iterator (usually as part of an enumerator/ee) and an iteratee. > Thanks for the attempt to explain. But I, at least, remain mystified, > and I agree with Douglas that the terminology is confusing. FWIW, I always thought it was a kind of pun on the iterators in OO-land. There, the iterator is a cursor-like object, and the program controls it to iterate over the input -- typically a collection or similar. Iteratees invert this, the "program" is in the form of an iteratee, and it is being iterated by the input (enumerator). So the iterator is actively controlling a passive (or reactive) input, while the iteratee is reactively processing an active or controlling input. Or something, I'm hardly an authority on this. I hope it makes sense. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More liberal than liberal type synonyms
On Wed, Dec 7, 2011 at 5:48 AM, Dmitry Kulagin wrote: > I am still pretty new in Haskell, but this problem annoys me already. > > If I define certain monad as a type synonym: > > type StateA a = StateT SomeState SomeMonad a > > Then I can't declare new monad based on the synonym: > > type StateB a = StateT SomeOtherState StateA a > > The only way I know to overcome is to declare StateA without `a': > > type StateA = StateT SomeState SomeMonad > > But it is not always possible with existing code base. I'm afraid my proposal doesn't make this work. You could perhaps define StateB, but when you expand in a type you get: StateB a = StateT SomeOtherState StateA a which has a partially applied StateA, and is rejected. The only way to make this work is to eta reduce StateA manually, or make GHC recognize when a synonym can be eta reduced in this way (which might be both possible and useful as a separate proposal). My extension fell within the liberal type synonym space, which says that if you have: F G where F and G are both synonyms, and G is partially applied, then it is okay as long as expansion of F (and any subsequent expansions) cause G to become fully applied. My extension of this is just to allow partial application inside aliases as long as it meets these same criteria. The reason to disallow partially applied type aliases is that they make inference pretty much impossible, unless you only infer them in very limited circumstances perhaps. And if you can't get inference of them, you probably need to start having explicit annotations to tell the type checker what you want to happen, which has some of its own complications with the way quantifiers work in GHC and such. It'd cascade into some thorny issues. Hopefully that covers all the other subsequent stuff folks have been talking about. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How did iteratees get their names?
Hi Ertugrul, > Coroutines actually capture this kind of composition (where some code > interrupts itself to hand control over to some other code) very well. > Perhaps it would be better to use terms from that abstraction instead. > In fact, iteratees are a special case of coroutines. That would seem to make sense, if there is appropriate terminology. And if we are indeed talking about co-routines, i.e. cooperation between peers, routines of equal status, that would in itself suggest that the X-or and X-ee names that imply an asymmetric relationship are somewhat unfortunate choices conveying the wrong intuition. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More liberal than liberal type synonyms
On Wed, Dec 7, 2011 at 1:07 PM, Dmitry Kulagin wrote: >> For short, type synonyms work for mere aliases, but not for full-fledged> >> type-level non-inductive functions.> And sometimes we intuitively want to >> use them as such. > Thank you, Yves! It is now more clear for me. > > Still, it seems that ability to use partially applied type synonyms would be > very natural (and useful) extension to the language. It would allow to avoid > boilerplate code associated with creating "really new" types instead of just > using synonims for existing ones. The problem as I understand it is that partially-applied type synonyms are in effect type level lambdas, and type checking in the presence of type level lambdas requires higher-order unification, which is undecidable in general. Restricted cases might be possible, I'm not an expert in the field. GHC hackers could probably elaborate. [1] http://stackoverflow.com/questions/8248217/are-there-type-level-combinators-will-they-exist-in-some-future [2] http://en.wikipedia.org/wiki/Unification_(computer_science)#Higher-order_unification > > On Wed, Dec 7, 2011 at 3:51 PM, Yves Parès wrote: >> Ah, maybe Dan could tell us if it works only with GHC 7. >> >> Dmitry, I had your problem many times. The last time was when I saw you >> could define the ContT monad in terms of Cont (the opposite is done in the >> mtl). >> It leads to a simpler code, but you are stucked when trying to define ContT >> as an instance of MonadTrans: >> >> data Cont r a = ... >> -- [instances of Monad Cont, blah blah blah] >> >> type ContT r m a = Cont r (m a) >> >> instance MonadTrans (ContT r) where -- This doesn't compile, even if it is >> logical >> lift = ... >> >> For short, type synonyms work for mere aliases, but not for full-fledged >> type-level non-inductive functions. >> And sometimes we intuitively want to use them as such. >> >> >> 2011/12/7 Dmitry Kulagin >>> >>> > Dmitry, does your code work with LiberalTypeSynonyms extention >>> > activated? >>> No, the same error: >>> Type synonym `StateA' should have 1 argument, but has been given 0 >>> >>> But I have GHC 6.12.3 >>> >>> Dmitry >>> 2011/12/7 Yves Parès : >>> > This is impossible: >>> > in the definition of 'StateT s m a', m must be a monad and then have the >>> > * >>> > -> * kind. >>> > So you cannot pass (StateA a), because it has simply the * kind. >>> > >>> > Dmitry, does your code work with LiberalTypeSynonyms extention >>> > activated? >>> > >>> > >>> > 2011/12/7 Øystein Kolsrud >>> >> >>> >> You should be able to write something like this: >>> >> >>> >> type StateB a b = StateT SomeOtherState (StateA a) b >>> >> >>> >> Best regards, Øystein Kolsrud >>> >> >>> >> >>> >> On Wed, Dec 7, 2011 at 11:48 AM, Dmitry Kulagin >>> >> >>> >> wrote: >>> >>> >>> >>> Hi Dan, >>> >>> >>> >>> I am still pretty new in Haskell, but this problem annoys me already. >>> >>> >>> >>> If I define certain monad as a type synonym: >>> >>> >>> >>> type StateA a = StateT SomeState SomeMonad a >>> >>> >>> >>> Then I can't declare new monad based on the synonym: >>> >>> >>> >>> type StateB a = StateT SomeOtherState StateA a >>> >>> >>> >>> The only way I know to overcome is to declare StateA without `a': >>> >>> >>> >>> type StateA = StateT SomeState SomeMonad >>> >>> >>> >>> But it is not always possible with existing code base. >>> >>> >>> >>> I am sorry, if this is offtopic, but it seemed to me that the problem >>> >>> is realted to partially applied type synomyms you described. >>> >>> >>> >>> Thanks! >>> >>> Dmitry >>> >>> >>> >>> On Tue, Dec 6, 2011 at 10:59 PM, Dan Doel wrote: >>> >>> > Greetings, >>> >>> > >>> >>> > In the process of working on a Haskell-alike language recently, Ed >>> >>> > Kmett and I realized that we had (without really thinking about it) >>> >>> > implemented type synonyms that are a bit more liberal than GHC's. >>> >>> > With >>> >>> > LiberalTypeSynonyms enabled, GHC allows: >>> >>> > >>> >>> > type Foo a b = b -> a >>> >>> > type Bar f = f String Int >>> >>> > >>> >>> > baz :: Bar Foo >>> >>> > baz = show >>> >>> > >>> >>> > because Bar expands to saturate Foo. However, we had also >>> >>> > implemented >>> >>> > the following, which fails in GHC: >>> >>> > >>> >>> > type Foo a b = b -> a >>> >>> > type Bar f = f (Foo Int) (Foo Int) >>> >>> > type Baz f g = f Int -> g Int >>> >>> > >>> >>> > quux :: Bar Baz >>> >>> > quux = id >>> >>> > >>> >>> > That is: type synonyms are allowed to be partially applied within >>> >>> > other type synonyms, as long as similar transitive saturation >>> >>> > guarantees are met during their use. >>> >>> > >>> >>> > I don't know how useful it is, but I was curious if anyone can see >>> >>> > anything wrong with allowing this (it seems okay to me after a >>> >>> > little >>> >>> > thought), and thought I'd float the idea out to the GHC developers, >>> >>> > in >>> >>> > case they're interested in picking it up. >>> >>> > >>> >>> > -- Dan >>> >>>
Re: [Haskell-cafe] How did iteratees get their names?
Henrik Nilsson wrote: > > Just like chatter and chattee, employer and employee, there is an > > iterator (usually as part of an enumerator/ee) and an iteratee. > > Thanks for the attempt to explain. But I, at least, remain mystified, > and I agree with Douglas that the terminology is confusing. > > Usually, the relationship between word-pairs such as the ones above is > pretty obvious, typically implying some kind of subordinate > relationship. For example: > >* employer: the one employing > employee: the one employed > >* tutor: the one teaching, instructing, providing care > tutee: the one receiving instruction, care > >* caller: that which is calling > callee: that which is being called > > And so on. > > The above would suggest that "iterator" would be something that > iterates over something, and that "iteratee" would be (an element of) > that being iterated over. You are right. In that case it really doesn't make sense. However, one way to make sense of this is that the iteratee is indeed being iterated over. Consider that the iteratee /contains/ the stream. The stream isn't fed from outside, because the enumerator itself is an iteratee and that one creates the stream in the first place. > However, no such simple relationship seems to emerge from the > provided explanation. > > I also had a look at John Millikin's page on Understanding Iteratees, > which is very good: > > https://john-millikin.com/articles/understanding-iteratees/ > > But, the intuition that comes across there is: > >* iteratee: a stream (of sorts) consumer > >* enumerator: a stream (of sorts) producer > >* enumeratee: a stream (of sorts) transformer > > And "iterator" isn't mentioned at all. That's because the iterator isn't part of the system at all. You bring in the iterator from outside. For example a loop reading chunks from a file is an iterator. That iterator is used inside of an enumerator, which is itself an iteratee that transforms another iteratee (in that it handles the Continue state). > I might be missing something, but the terminology is hardly crystal > clear. Which is a pity! That's true, but on the other hand personally I wouldn't know how to improve it without giving a wrong intuition. Coroutines actually capture this kind of composition (where some code interrupts itself to hand control over to some other code) very well. Perhaps it would be better to use terms from that abstraction instead. In fact, iteratees are a special case of coroutines. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
Quoth Felipe Almeida Lessa , > On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery wrote: >> They *do* terminate; a zombie is a dead process waiting for its parent to >> reap it with waitForProcess. There's also some POSIX stuff you can do to >> have them auto-reaped, but doing that correctly and portably is somewhat >> painful. > > But zombie processes do consume a row in the process table, right? If > so, then it's bad to have them around. Correct. As noted above, clean up with waitForProcess to release this resource. If it's more convenient, that could be done up front, by forking twice and waiting for the intermediate process. One possibly convenient way to do that might be something like runCommand "eprover &". Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
On Wed, Dec 7, 2011 at 10:27, Felipe Almeida Lessa wrote: > On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery > wrote: > > They *do* terminate; a zombie is a dead process waiting for its parent to > > reap it with waitForProcess. There's also some POSIX stuff you can do to > > have them auto-reaped, but doing that correctly and portably is somewhat > > painful. > > But zombie processes do consume a row in the process table, right? If > so, then it's bad to have them around. Yes, and they count against the per-uid process limit. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery wrote: > They *do* terminate; a zombie is a dead process waiting for its parent to > reap it with waitForProcess. There's also some POSIX stuff you can do to > have them auto-reaped, but doing that correctly and portably is somewhat > painful. But zombie processes do consume a row in the process table, right? If so, then it's bad to have them around. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How did iteratees get their names?
Hi, Ertugrul wrote: > Just like chatter and chattee, employer and employee, there is an > iterator (usually as part of an enumerator/ee) and an iteratee. Thanks for the attempt to explain. But I, at least, remain mystified, and I agree with Douglas that the terminology is confusing. Usually, the relationship between word-pairs such as the ones above is pretty obvious, typically implying some kind of subordinate relationship. For example: * employer: the one employing employee: the one employed * tutor: the one teaching, instructing, providing care tutee: the one receiving instruction, care * caller: that which is calling callee: that which is being called And so on. The above would suggest that "iterator" would be something that iterates over something, and that "iteratee" would be (an element of) that being iterated over. However, no such simple relationship seems to emerge from the provided explanation. I also had a look at John Millikin's page on Understanding Iteratees, which is very good: https://john-millikin.com/articles/understanding-iteratees/ But, the intuition that comes across there is: * iteratee: a stream (of sorts) consumer * enumerator: a stream (of sorts) producer * enumeratee: a stream (of sorts) transformer And "iterator" isn't mentioned at all. I might be missing something, but the terminology is hardly crystal clear. Which is a pity! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
On Wed, Dec 7, 2011 at 06:47, Dan Rosén wrote: > I'm using Haskell to run a lot of instances of an Automated Thorem Prover, > eprover. I have pasted a smaller version of my program at > http://hpaste.org/54954. It runs eprover sequentially on all input files, > with a timeout of 100ms. Unfortunately, it leaves a lot of zombie processes > around, probably due to the fact that terminateProcess fails to terminate > them, even though eprover terminates on SIGTERM. > They *do* terminate; a zombie is a dead process waiting for its parent to reap it with waitForProcess. There's also some POSIX stuff you can do to have them auto-reaped, but doing that correctly and portably is somewhat painful. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How did iteratees get their names?
Douglas McClean wrote: > I love iteratees as a paradigm for IO, but I am having trouble > developing a relationship with the names. Could someone explain their > origin? > > It seems like if iteratees consume things, enumerators produce them, > andenumeratees do both that names like Sink, Source, and Transformer > or Consumer, Producer, and Transformer might be more relatable > choices? Is there some reason apart from convention why these names > wouldn't fit the concepts well? Well, everything in the iteratee concept is an iteratee. An enumerator is itself an iteratee (that usually just isn't fed with input). Hence those clearer names wouldn't really fit. An enumeratee is an iteratee that takes another iteratee and feeds it with input. It might use its own input for that. An enumerator is a special case of that, which ignores its own input. Just like chatter and chattee, employer and employee, there is an iterator (usually as part of an enumerator/ee) and an iteratee. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PhD position at Ghent University
The Programming Languages Group of Ghent University invites applicants for a PhD position. This position centers around the modular treatment of side-effects in purely functional programs and models. It is part of the project "Modular handling of effects in purely functional programs and models" under the direction of Tom Schrijvers. The successful applicant has a master degree in Computer Science or equivalent. Ideally, she/he will also have a strong, documented interest in doing research. Strong problem-solving and programming skills are essential. Prior knowledge of purely functional programming (e.g., Haskell) and models of side-effects (e.g., monads) is an advantage. The PhD position is for 4 years. It starts between January and October 2012. The position is a fully-funded post. The salary is compatible with other Belgian PhD rates and among the better ones in Europe and abroad. For more information, see: http://users.ugent.be/~tschrijv/phdposition2.html -- prof. dr. ir. Tom Schrijvers Programming Languages Group Department of Applied Mathematics and Computer Science University of Ghent Krijgslaan 281 S9 9000 Gent Belgium Phone: +32 9 264 4805 http://users.ugent.be/~tschrijv/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
Quick suggestion: did you try using waitForProcess just after terminateProcess? Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More liberal than liberal type synonyms
> For short, type synonyms work for mere aliases, but not for full-fledged> > type-level non-inductive functions.> And sometimes we intuitively want to use > them as such. Thank you, Yves! It is now more clear for me. Still, it seems that ability to use partially applied type synonyms would be very natural (and useful) extension to the language. It would allow to avoid boilerplate code associated with creating "really new" types instead of just using synonims for existing ones. On Wed, Dec 7, 2011 at 3:51 PM, Yves Parès wrote: > Ah, maybe Dan could tell us if it works only with GHC 7. > > Dmitry, I had your problem many times. The last time was when I saw you > could define the ContT monad in terms of Cont (the opposite is done in the > mtl). > It leads to a simpler code, but you are stucked when trying to define ContT > as an instance of MonadTrans: > > data Cont r a = ... > -- [instances of Monad Cont, blah blah blah] > > type ContT r m a = Cont r (m a) > > instance MonadTrans (ContT r) where -- This doesn't compile, even if it is > logical > lift = ... > > For short, type synonyms work for mere aliases, but not for full-fledged > type-level non-inductive functions. > And sometimes we intuitively want to use them as such. > > > 2011/12/7 Dmitry Kulagin >> >> > Dmitry, does your code work with LiberalTypeSynonyms extention >> > activated? >> No, the same error: >> Type synonym `StateA' should have 1 argument, but has been given 0 >> >> But I have GHC 6.12.3 >> >> Dmitry >> 2011/12/7 Yves Parès : >> > This is impossible: >> > in the definition of 'StateT s m a', m must be a monad and then have the >> > * >> > -> * kind. >> > So you cannot pass (StateA a), because it has simply the * kind. >> > >> > Dmitry, does your code work with LiberalTypeSynonyms extention >> > activated? >> > >> > >> > 2011/12/7 Øystein Kolsrud >> >> >> >> You should be able to write something like this: >> >> >> >> type StateB a b = StateT SomeOtherState (StateA a) b >> >> >> >> Best regards, Øystein Kolsrud >> >> >> >> >> >> On Wed, Dec 7, 2011 at 11:48 AM, Dmitry Kulagin >> >> >> >> wrote: >> >>> >> >>> Hi Dan, >> >>> >> >>> I am still pretty new in Haskell, but this problem annoys me already. >> >>> >> >>> If I define certain monad as a type synonym: >> >>> >> >>> type StateA a = StateT SomeState SomeMonad a >> >>> >> >>> Then I can't declare new monad based on the synonym: >> >>> >> >>> type StateB a = StateT SomeOtherState StateA a >> >>> >> >>> The only way I know to overcome is to declare StateA without `a': >> >>> >> >>> type StateA = StateT SomeState SomeMonad >> >>> >> >>> But it is not always possible with existing code base. >> >>> >> >>> I am sorry, if this is offtopic, but it seemed to me that the problem >> >>> is realted to partially applied type synomyms you described. >> >>> >> >>> Thanks! >> >>> Dmitry >> >>> >> >>> On Tue, Dec 6, 2011 at 10:59 PM, Dan Doel wrote: >> >>> > Greetings, >> >>> > >> >>> > In the process of working on a Haskell-alike language recently, Ed >> >>> > Kmett and I realized that we had (without really thinking about it) >> >>> > implemented type synonyms that are a bit more liberal than GHC's. >> >>> > With >> >>> > LiberalTypeSynonyms enabled, GHC allows: >> >>> > >> >>> > type Foo a b = b -> a >> >>> > type Bar f = f String Int >> >>> > >> >>> > baz :: Bar Foo >> >>> > baz = show >> >>> > >> >>> > because Bar expands to saturate Foo. However, we had also >> >>> > implemented >> >>> > the following, which fails in GHC: >> >>> > >> >>> > type Foo a b = b -> a >> >>> > type Bar f = f (Foo Int) (Foo Int) >> >>> > type Baz f g = f Int -> g Int >> >>> > >> >>> > quux :: Bar Baz >> >>> > quux = id >> >>> > >> >>> > That is: type synonyms are allowed to be partially applied within >> >>> > other type synonyms, as long as similar transitive saturation >> >>> > guarantees are met during their use. >> >>> > >> >>> > I don't know how useful it is, but I was curious if anyone can see >> >>> > anything wrong with allowing this (it seems okay to me after a >> >>> > little >> >>> > thought), and thought I'd float the idea out to the GHC developers, >> >>> > in >> >>> > case they're interested in picking it up. >> >>> > >> >>> > -- Dan >> >>> > >> >>> > ___ >> >>> > 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 >> >> >> >> >> >> >> >> >> >> -- >> >> Mvh Øystein Kolsrud >> >> >> >> ___ >> >> Haskell-Cafe mailing list >> >> Haskell-Cafe@haskell.org >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.or
Re: [Haskell-cafe] More liberal than liberal type synonyms
Ah, maybe Dan could tell us if it works only with GHC 7. Dmitry, I had your problem many times. The last time was when I saw you could define the ContT monad in terms of Cont (the opposite is done in the mtl). It leads to a simpler code, but you are stucked when trying to define ContT as an instance of MonadTrans: data Cont r a = ... -- [instances of Monad Cont, blah blah blah] type ContT r m a = Cont r (m a) instance MonadTrans (ContT r) where -- *This doesn't compile*, even if it is logical lift = ... For short, type synonyms work for mere aliases, but not for full-fledged type-level non-inductive functions. And sometimes we intuitively want to use them as such. 2011/12/7 Dmitry Kulagin > > Dmitry, does your code work with LiberalTypeSynonyms extention activated? > No, the same error: > Type synonym `StateA' should have 1 argument, but has been given 0 > > But I have GHC 6.12.3 > > Dmitry > 2011/12/7 Yves Parès : > > This is impossible: > > in the definition of 'StateT s m a', m must be a monad and then have the > * > > -> * kind. > > So you cannot pass (StateA a), because it has simply the * kind. > > > > Dmitry, does your code work with LiberalTypeSynonyms extention activated? > > > > > > 2011/12/7 Øystein Kolsrud > >> > >> You should be able to write something like this: > >> > >> type StateB a b = StateT SomeOtherState (StateA a) b > >> > >> Best regards, Øystein Kolsrud > >> > >> > >> On Wed, Dec 7, 2011 at 11:48 AM, Dmitry Kulagin < > dmitry.kula...@gmail.com> > >> wrote: > >>> > >>> Hi Dan, > >>> > >>> I am still pretty new in Haskell, but this problem annoys me already. > >>> > >>> If I define certain monad as a type synonym: > >>> > >>>type StateA a = StateT SomeState SomeMonad a > >>> > >>> Then I can't declare new monad based on the synonym: > >>> > >>>type StateB a = StateT SomeOtherState StateA a > >>> > >>> The only way I know to overcome is to declare StateA without `a': > >>> > >>>type StateA = StateT SomeState SomeMonad > >>> > >>> But it is not always possible with existing code base. > >>> > >>> I am sorry, if this is offtopic, but it seemed to me that the problem > >>> is realted to partially applied type synomyms you described. > >>> > >>> Thanks! > >>> Dmitry > >>> > >>> On Tue, Dec 6, 2011 at 10:59 PM, Dan Doel wrote: > >>> > Greetings, > >>> > > >>> > In the process of working on a Haskell-alike language recently, Ed > >>> > Kmett and I realized that we had (without really thinking about it) > >>> > implemented type synonyms that are a bit more liberal than GHC's. > With > >>> > LiberalTypeSynonyms enabled, GHC allows: > >>> > > >>> >type Foo a b = b -> a > >>> >type Bar f = f String Int > >>> > > >>> >baz :: Bar Foo > >>> >baz = show > >>> > > >>> > because Bar expands to saturate Foo. However, we had also implemented > >>> > the following, which fails in GHC: > >>> > > >>> >type Foo a b = b -> a > >>> >type Bar f = f (Foo Int) (Foo Int) > >>> >type Baz f g = f Int -> g Int > >>> > > >>> >quux :: Bar Baz > >>> >quux = id > >>> > > >>> > That is: type synonyms are allowed to be partially applied within > >>> > other type synonyms, as long as similar transitive saturation > >>> > guarantees are met during their use. > >>> > > >>> > I don't know how useful it is, but I was curious if anyone can see > >>> > anything wrong with allowing this (it seems okay to me after a little > >>> > thought), and thought I'd float the idea out to the GHC developers, > in > >>> > case they're interested in picking it up. > >>> > > >>> > -- Dan > >>> > > >>> > ___ > >>> > 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 > >> > >> > >> > >> > >> -- > >> Mvh Øystein Kolsrud > >> > >> ___ > >> 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] terminateProcess leaves zombie processes around
Hi Haskell-Cafe, I'm using Haskell to run a lot of instances of an Automated Thorem Prover, eprover. I have pasted a smaller version of my program at http://hpaste.org/54954. It runs eprover sequentially on all input files, with a timeout of 100ms. Unfortunately, it leaves a lot of zombie processes around, probably due to the fact that terminateProcess fails to terminate them, even though eprover terminates on SIGTERM. I have tried to use System.Timeout.timeout around readProcess, but without surprise it did not work. Another way of doing it is to use the timeout from gnu-coreutils, but the timeout resolution is in seconds (same with eprover's flag --cpu-limit). Any ideas how I could write my code to get a clean termination of this process? Best, Dan Rosén ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More liberal than liberal type synonyms
> Dmitry, does your code work with LiberalTypeSynonyms extention activated? No, the same error: Type synonym `StateA' should have 1 argument, but has been given 0 But I have GHC 6.12.3 Dmitry 2011/12/7 Yves Parès : > This is impossible: > in the definition of 'StateT s m a', m must be a monad and then have the * > -> * kind. > So you cannot pass (StateA a), because it has simply the * kind. > > Dmitry, does your code work with LiberalTypeSynonyms extention activated? > > > 2011/12/7 Øystein Kolsrud >> >> You should be able to write something like this: >> >> type StateB a b = StateT SomeOtherState (StateA a) b >> >> Best regards, Øystein Kolsrud >> >> >> On Wed, Dec 7, 2011 at 11:48 AM, Dmitry Kulagin >> wrote: >>> >>> Hi Dan, >>> >>> I am still pretty new in Haskell, but this problem annoys me already. >>> >>> If I define certain monad as a type synonym: >>> >>> type StateA a = StateT SomeState SomeMonad a >>> >>> Then I can't declare new monad based on the synonym: >>> >>> type StateB a = StateT SomeOtherState StateA a >>> >>> The only way I know to overcome is to declare StateA without `a': >>> >>> type StateA = StateT SomeState SomeMonad >>> >>> But it is not always possible with existing code base. >>> >>> I am sorry, if this is offtopic, but it seemed to me that the problem >>> is realted to partially applied type synomyms you described. >>> >>> Thanks! >>> Dmitry >>> >>> On Tue, Dec 6, 2011 at 10:59 PM, Dan Doel wrote: >>> > Greetings, >>> > >>> > In the process of working on a Haskell-alike language recently, Ed >>> > Kmett and I realized that we had (without really thinking about it) >>> > implemented type synonyms that are a bit more liberal than GHC's. With >>> > LiberalTypeSynonyms enabled, GHC allows: >>> > >>> > type Foo a b = b -> a >>> > type Bar f = f String Int >>> > >>> > baz :: Bar Foo >>> > baz = show >>> > >>> > because Bar expands to saturate Foo. However, we had also implemented >>> > the following, which fails in GHC: >>> > >>> > type Foo a b = b -> a >>> > type Bar f = f (Foo Int) (Foo Int) >>> > type Baz f g = f Int -> g Int >>> > >>> > quux :: Bar Baz >>> > quux = id >>> > >>> > That is: type synonyms are allowed to be partially applied within >>> > other type synonyms, as long as similar transitive saturation >>> > guarantees are met during their use. >>> > >>> > I don't know how useful it is, but I was curious if anyone can see >>> > anything wrong with allowing this (it seems okay to me after a little >>> > thought), and thought I'd float the idea out to the GHC developers, in >>> > case they're interested in picking it up. >>> > >>> > -- Dan >>> > >>> > ___ >>> > 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 >> >> >> >> >> -- >> Mvh Øystein Kolsrud >> >> ___ >> 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] More liberal than liberal type synonyms
This is impossible: in the definition of 'StateT s m a', m must be a monad and then have the * -> * kind. So you cannot pass (StateA a), because it has simply the * kind. Dmitry, does your code work with LiberalTypeSynonyms extention activated? 2011/12/7 Øystein Kolsrud > You should be able to write something like this: > > type StateB a b = StateT SomeOtherState (StateA a) b > > Best regards, Øystein Kolsrud > > > On Wed, Dec 7, 2011 at 11:48 AM, Dmitry Kulagin > wrote: > >> Hi Dan, >> >> I am still pretty new in Haskell, but this problem annoys me already. >> >> If I define certain monad as a type synonym: >> >>type StateA a = StateT SomeState SomeMonad a >> >> Then I can't declare new monad based on the synonym: >> >>type StateB a = StateT SomeOtherState StateA a >> >> The only way I know to overcome is to declare StateA without `a': >> >>type StateA = StateT SomeState SomeMonad >> >> But it is not always possible with existing code base. >> >> I am sorry, if this is offtopic, but it seemed to me that the problem >> is realted to partially applied type synomyms you described. >> >> Thanks! >> Dmitry >> >> On Tue, Dec 6, 2011 at 10:59 PM, Dan Doel wrote: >> > Greetings, >> > >> > In the process of working on a Haskell-alike language recently, Ed >> > Kmett and I realized that we had (without really thinking about it) >> > implemented type synonyms that are a bit more liberal than GHC's. With >> > LiberalTypeSynonyms enabled, GHC allows: >> > >> >type Foo a b = b -> a >> >type Bar f = f String Int >> > >> >baz :: Bar Foo >> >baz = show >> > >> > because Bar expands to saturate Foo. However, we had also implemented >> > the following, which fails in GHC: >> > >> >type Foo a b = b -> a >> >type Bar f = f (Foo Int) (Foo Int) >> >type Baz f g = f Int -> g Int >> > >> >quux :: Bar Baz >> >quux = id >> > >> > That is: type synonyms are allowed to be partially applied within >> > other type synonyms, as long as similar transitive saturation >> > guarantees are met during their use. >> > >> > I don't know how useful it is, but I was curious if anyone can see >> > anything wrong with allowing this (it seems okay to me after a little >> > thought), and thought I'd float the idea out to the GHC developers, in >> > case they're interested in picking it up. >> > >> > -- Dan >> > >> > ___ >> > 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 >> > > > > -- > Mvh Øystein Kolsrud > > ___ > 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] More liberal than liberal type synonyms
> You should be able to write something like this: > > type StateB a b = StateT SomeOtherState (StateA a) b Thank you for reply, but this variant actually does not compile: StateA and (StateA a) have different kinds. Dmitry > > Best regards, Øystein Kolsrud > > > On Wed, Dec 7, 2011 at 11:48 AM, Dmitry Kulagin > wrote: >> >> Hi Dan, >> >> I am still pretty new in Haskell, but this problem annoys me already. >> >> If I define certain monad as a type synonym: >> >> type StateA a = StateT SomeState SomeMonad a >> >> Then I can't declare new monad based on the synonym: >> >> type StateB a = StateT SomeOtherState StateA a >> >> The only way I know to overcome is to declare StateA without `a': >> >> type StateA = StateT SomeState SomeMonad >> >> But it is not always possible with existing code base. >> >> I am sorry, if this is offtopic, but it seemed to me that the problem >> is realted to partially applied type synomyms you described. >> >> Thanks! >> Dmitry >> >> On Tue, Dec 6, 2011 at 10:59 PM, Dan Doel wrote: >> > Greetings, >> > >> > In the process of working on a Haskell-alike language recently, Ed >> > Kmett and I realized that we had (without really thinking about it) >> > implemented type synonyms that are a bit more liberal than GHC's. With >> > LiberalTypeSynonyms enabled, GHC allows: >> > >> > type Foo a b = b -> a >> > type Bar f = f String Int >> > >> > baz :: Bar Foo >> > baz = show >> > >> > because Bar expands to saturate Foo. However, we had also implemented >> > the following, which fails in GHC: >> > >> > type Foo a b = b -> a >> > type Bar f = f (Foo Int) (Foo Int) >> > type Baz f g = f Int -> g Int >> > >> > quux :: Bar Baz >> > quux = id >> > >> > That is: type synonyms are allowed to be partially applied within >> > other type synonyms, as long as similar transitive saturation >> > guarantees are met during their use. >> > >> > I don't know how useful it is, but I was curious if anyone can see >> > anything wrong with allowing this (it seems okay to me after a little >> > thought), and thought I'd float the idea out to the GHC developers, in >> > case they're interested in picking it up. >> > >> > -- Dan >> > >> > ___ >> > 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 > > > > > -- > Mvh Øystein Kolsrud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More liberal than liberal type synonyms
You should be able to write something like this: type StateB a b = StateT SomeOtherState (StateA a) b Best regards, Øystein Kolsrud On Wed, Dec 7, 2011 at 11:48 AM, Dmitry Kulagin wrote: > Hi Dan, > > I am still pretty new in Haskell, but this problem annoys me already. > > If I define certain monad as a type synonym: > >type StateA a = StateT SomeState SomeMonad a > > Then I can't declare new monad based on the synonym: > >type StateB a = StateT SomeOtherState StateA a > > The only way I know to overcome is to declare StateA without `a': > >type StateA = StateT SomeState SomeMonad > > But it is not always possible with existing code base. > > I am sorry, if this is offtopic, but it seemed to me that the problem > is realted to partially applied type synomyms you described. > > Thanks! > Dmitry > > On Tue, Dec 6, 2011 at 10:59 PM, Dan Doel wrote: > > Greetings, > > > > In the process of working on a Haskell-alike language recently, Ed > > Kmett and I realized that we had (without really thinking about it) > > implemented type synonyms that are a bit more liberal than GHC's. With > > LiberalTypeSynonyms enabled, GHC allows: > > > >type Foo a b = b -> a > >type Bar f = f String Int > > > >baz :: Bar Foo > >baz = show > > > > because Bar expands to saturate Foo. However, we had also implemented > > the following, which fails in GHC: > > > >type Foo a b = b -> a > >type Bar f = f (Foo Int) (Foo Int) > >type Baz f g = f Int -> g Int > > > >quux :: Bar Baz > >quux = id > > > > That is: type synonyms are allowed to be partially applied within > > other type synonyms, as long as similar transitive saturation > > guarantees are met during their use. > > > > I don't know how useful it is, but I was curious if anyone can see > > anything wrong with allowing this (it seems okay to me after a little > > thought), and thought I'd float the idea out to the GHC developers, in > > case they're interested in picking it up. > > > > -- Dan > > > > ___ > > 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 > -- Mvh Øystein Kolsrud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More liberal than liberal type synonyms
Hi Dan, I am still pretty new in Haskell, but this problem annoys me already. If I define certain monad as a type synonym: type StateA a = StateT SomeState SomeMonad a Then I can't declare new monad based on the synonym: type StateB a = StateT SomeOtherState StateA a The only way I know to overcome is to declare StateA without `a': type StateA = StateT SomeState SomeMonad But it is not always possible with existing code base. I am sorry, if this is offtopic, but it seemed to me that the problem is realted to partially applied type synomyms you described. Thanks! Dmitry On Tue, Dec 6, 2011 at 10:59 PM, Dan Doel wrote: > Greetings, > > In the process of working on a Haskell-alike language recently, Ed > Kmett and I realized that we had (without really thinking about it) > implemented type synonyms that are a bit more liberal than GHC's. With > LiberalTypeSynonyms enabled, GHC allows: > > type Foo a b = b -> a > type Bar f = f String Int > > baz :: Bar Foo > baz = show > > because Bar expands to saturate Foo. However, we had also implemented > the following, which fails in GHC: > > type Foo a b = b -> a > type Bar f = f (Foo Int) (Foo Int) > type Baz f g = f Int -> g Int > > quux :: Bar Baz > quux = id > > That is: type synonyms are allowed to be partially applied within > other type synonyms, as long as similar transitive saturation > guarantees are met during their use. > > I don't know how useful it is, but I was curious if anyone can see > anything wrong with allowing this (it seems okay to me after a little > thought), and thought I'd float the idea out to the GHC developers, in > case they're interested in picking it up. > > -- Dan > > ___ > 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] Neither of the sparks are converted into OS threads but parallelization happens surprisingly!!!
Dear List, I have a point misunderstood! I am using second generation strategies of Haskell to parallelize some number of algorithms in Haskell. The missing point here is that: In some cases, neither of created sparks are converted into OS threads, but parallelization happens surprisingly, when I use threadscope to see what had happened during the evaluation. What happened to me was that 2 sparks were created one of which was pruned, none of which was converted into OS threads and the last one was missing, however, parallelism happened!!! I wonder what is the reason for this? Could someone aware, please shed light on the issue? Thanks in advance. Saluti, Burak. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
