- Haskell-Cafe - Haskell.org

My try for a CoroutineT monad tranformer
by Joachim Breitner 26 Apr '08

26 Apr '08

Hi, (for those who follow planet.haskell.org this is old news, but I thought I’d tell the others) In http://www.joachim-breitner.de/blog/archives/291-Pausable-IO-actions-for-be… I describe how I wrote a monad transformer that allows me to pause a computation from within by returning another computation that I can use to re-start the computation (or to throw it away if I want). I needed this for a long running drawing computation in a gtk2hs program that I want to pause at convenient points (to allow user interaction), and that I need to abort when what I’m drawing is not up-to-date anymore. The API basically consists of the function > runCoroutineT :: Monad m => CoroutineT m () -> m (Maybe (CoroutineT m ())) which runs the pausable computation, any Maybe returns Just the resume action, and the function > pause :: Monad m => CoroutineT m () to be used inside the computation, which pauses it. I have put the complete module in the darcs repository that might later also contain the GUI program at http://darcs.nomeata.de/FrakView/ What do you think of CoroutineT? Could it have been easily implemented using the existing monad transformers? Is it useful enough so that it should be included somewhere, and where? Are there any problems with strictness or other tripping points that I have overlooked? Greetings, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata(a)joachim-breitner.de

3 4

I hate Haskell's typeclasses
by Ryan Ingram 25 Apr '08

25 Apr '08

WARNING: RANT AHEAD. Hopefully this fires off some productive discussion on how to fix these problems! Don't get me wrong: I think the idea of typeclasses is great. Their implementation in Haskell comes so close to being awesome and then falls short, and that's almost worse than not being awesome in the first place! Some examples of things I think you should be able to do, that just Do Not Work. Examples like these are trivial in many other languages, and they shouldn't be that hard here, either! 1) You can't make sensible default implementations. For example, it'd be nice to make all my Monads be Applicatives and Functors without resorting to Template Haskell or infinite boilerplate. Why can't I just write this? instance Monad m => Applicative m where pure = return (<*>) = ap Sure, I get that there might be ambiguity of which instance to choose. But why not warn me about that ambiguity, or let me choose somehow on a case-by-case basis when it happens? 2) You can't add sensible superclasses. I was playing with QuickCheck and wanted to write "equal with regards to testing". So I wrote up a class for it: class TestableEq a where (~=) :: a -> a -> Property instance Eq a => TestableEq a where -- should be a superclass of Eq instead! a ~= b = a == b instance (Arbitrary a, TestableEq b) => TestableEq (a -> b) where f ~= g = forAll arbitrary (\a -> f a ~= g a) But this doesn't work without overlapping & undecidable instances! Sure, there is an alternative: I could manually declare instances of TestableEq for EVERY SINGLE TYPE that is an instance of Eq. I am sure nobody here would actually suggest that I do so. And sure, these extensions are both safe here, because the intent is that you won't declare instances of TestableEq for things that are already instances of Eq, and you won't do something stupid like "instance TestableEq a => Eq a". But why do I need to jump through these hoops for a perfectly safe & commonly desired operation? 3) There's no reflection or ability to choose an implementation based on other constraints. In QuickCheck, (a -> b) is an instance of Arbitrary for appropriate a, b. But you can't use this instance in forAll or for testing functions without being an instance of Show. Now, this is probably a design mistake, but it's the right choice with the current typeclass system (see (2)). But it'd be a million times better to have something like the following: class Arbitrary a => MkArbitrary a where mkArbitrary :: Gen (a, String) case instance MkArbitrary a where Show a => mkArbitrary = do x <- arbitrary return (x, show x) otherwise => mkArbitrary = do st <- getGenState x <- arbitrary return (x, "evalGen arbitrary " ++ show st) With this, QuickCheck could print reproducible test cases painlessly without adding the requirement that everything is an instance of Show! Now, you could say that mkArbitrary should be a member function of Arbitrary, but then you clutter up your instance definitions with tons of "mkArbitrary = defaultMkArbitrary" for types that have a Show instance. 4) Every concrete type should be an instance of Typeable without having to do anything, and Typeable should give you typecase & reflection: genericShow :: Typeable a => a -> String genericShow x = typecase x of String -> x (Show t => t) -> show x -- any instance of Show _ -> "<unknown>" -- ryan P.S. I'd actually love to work on any or all of these problems, but I can't get GHC to compile! See http://hpaste.org/5878

8 16

looking for examples of non-full Functional Dependencies
by Tom Schrijvers 25 Apr '08

25 Apr '08

Hello, I'm looking for practical examples of non-full functional dependencies and would be grateful if anyone could show me some or point to applications using them. A non-full functional dependency is one involves only part of the parameters of a type class. E.g. class C a b c | a -> b has a non-full functional dependency a -> b which does not involve c. Thanks, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers(a)cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/

13 35

Higher order randomness and the fat tails
by Steve Lihn 25 Apr '08

25 Apr '08

Hi, Haskellers, This email is only remotely connected to this list. Recently I am doing some research on the fat tails (in fact, I simply bumped into it) on the stock market. I came up with an equation which I think solves the fat tails -- which is really the Levy stable distribution. During the complex arguments that led to the solution, I coined a term called "Higher order randomness". This is inspired by the concept of higher order function in Haskell. * Higher order function operates on another function, instead on an ordinary value. So higher order randomness operates on another randomness, instead of directly producing the time series. The request is the following. I know there are many scientists on this list. If you or your colleagues happen to be involved or know any scenario that has fat tail distribution, can you let me know? I only "solved" one scenario -- numerically, not even analytically. Probability-wise, it is a dangerous thing to claim I solve "the problem". So I'd like to collect as many scenarios as I can. It can be financial related, or in other fields of science. PS. I'd like to have some operational details and numbers. Not just a general statement like "fat tail is observed in astronomy". Thanks and sorry for the spam, Steve

1 0

how can this code be less?
by cetin tozkoparan 25 Apr '08

25 Apr '08

I wrote this code and Can it be less? [2,4,5]list is sub list of [3,7,2,4,5,9] list and return True but not of[3,7,4,2,5,9] list ; return False sublist :: Eq a => [a] -> [a] -> Bool sublist [] _ = True sublist (_:_) [] = False sublist (x:xs) (y:ys) | x == y = if isEqual (x:xs) (y:ys) == False then sublist (x:xs) ys else True | otherwise = sublist (x:xs) ys isEqual :: Eq a => [a] -> [a] -> Bool isEqual [] _ = True isEqual (_:_) [] = False isEqual (x:xs) (y:ys) | x==y = isEqual xs ys | otherwise = False ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

5 5

Help me refactor this type!
by Ryan Ingram 25 Apr '08

25 Apr '08

More FRP stuff: a new type for Future that came to me in an inspiration this morning. But it's ugly and I need someone with better theoretical underpinnings than me to tell me what I've really built :) data Future t a = Known t a | Unknown (t -> IO (STM (Maybe (Future t a)))) Given Eq t, Ord t, Bounded t, this type is at least member of Monad, Applicative, Functor, and MonadPlus/Monoid. But the derivation gives me that "needs refactoring" feeling; here's an example: force :: (Ord t, Bounded t) => Future t a -> IO (t, a) force (Known t a) = return (t, a) force (Unknown f) = do stmF <- f maxBound mF <- atomically stmF case mF of Nothing -> return (maxBound, error "never") Just fut' -> force fut' delayF :: Ord t => t -> Future t a -> Future t a delayF t0 (Known t a) = Known (max t0 t) a delayF t0 (Unknown f) = Unknown $ \t -> fmap (fmap (fmap (delayF t0))) (f t) instance (Ord t, Bounded t) => Monad (Future t) where return = Known minBound Known t a >>= g = delayF t (g a) Unknown f >>= g = Unknown $ \t -> do -- IO stmF <- f t return $ do -- STM mF <- stmF return $ do -- Maybe fut' <- mF return (fut' >>= g) This code makes me sad; so many nested blocks. There's got to be a refactoring of this that I am missing! It's clearly got something to do with Fix, Either, ReaderT, and MaybeT, and type composition, but none of those seem to answer the whole question. Any thoughts? -- ryan

3 2

Stronger STM primitives needed? Or am I just doing it wrong?
by Ryan Ingram 25 Apr '08

25 Apr '08

How can I implement the following operation efficiently in STM? Given a TVar "now", waitFor t0 = do t <- readTVar now if (t < t0) then retry else return () This naive implementation has the problem that the transaction gets restarted every time "now" gets updated, even if the new value is still less than t0. One primitive that would be strong enough is this: retryUntil :: TVar a -> (a -> Bool) -> STM () although it would still do some computation every time "now" changed. The thought I originally had was to register the "waitFor" time with some helper which kept track of the current time and fired off a notice when it was ready. But the problem with that is that "retry" undoes all the work of setting that up; the goal is still to block, but I want a stronger blocking primitive. Does anyone have any ideas? -- ryan Here's the background: I'm following along with Conal's excellent FRP paper at http://conal.net/papers/simply-reactive/ In his implementation of futures, Conal uses a race primitive which spawns two threads each computing a value that (if successful) is guaranteed to agree. I was (and still am) sure that an implementation using STM could avoid needing to race, with careful use of orElse & retry. Here's the datatype I'm using for Future: > -- semantic type for future > -- t = type of Time, an instance of Bounded. a = value type > type F t a = (t, a) > force :: Future t a -> F t a > data Future t a = Fut > { waitFor :: t -> STM () > , value :: STM (t, a) > } > firstFuture :: Future t a -> Future t a -> Future t a > -- with semantics: > -- force (firstFuture f1 f2) = (min t1 t2, if t1 <= t2 then v1 else v2) > -- where > -- (t1, v1) = force f1 > -- (t2, v2) = force f2 Each future lives in some universe; imagine you have the following: ] type Universe t -- abstract ] P :: Bounded t => Universe t -- universe of pure values ] R :: Universe Time -- universe of the real world ] univ :: Future t a -> Universe t ] now :: Universe t -> STM t ] -- now P = return maxBound ] -- now R = current time The main thrust of this is that each universe has its own idea of what time it is; but when combining futures, we get a new universe which tracks the later of the times in the two universes. The problem is combining two futures: Lets say we have: anyKey :: Future Time () -- fires when the user first presses a key thousand :: Num t => Future t () -- fires at tick 1000 thousand = exactly 1000 () and we are evaluating force (firstFuture anyKey thousand) Now, "clock" is going to fire at tick 1000; we know this because it lives in the pure universe and its value is always available. So firstFuture can get the following: x1 <- maybeSTM (value anyKey) -- x1 = Nothing x2 <- maybeSTM (value clock) -- x2 = Just (1000, ()) ... -- synchronize P with R at tick 1000 waitFor anyKey 1000 -- if nothing has changed before tick 1000 return (1000, ()) -- converts a possibly-retry-calling STM into one that never fails maybeSTM m = fmap Just m `orElse` return Nothing So if we use the naive implementation for "waitFor" in terms of "now", the whole transaction will get re-evaluated every tick. I only want it to get re-evaluated if the user presses a key (changing some TVar evaluated in "value anyKey"), or tick 1000 passes, whichever comes first. Is there a way to do this? Is my choice of "waitFor" as the basic "universe synchronization" operation too weak?

9 25

Kieran Beltran/Watson/IBM is out of the office.
by Kieran Beltran 25 Apr '08

25 Apr '08

I will be out of the office starting 04/23/2008 and will not return until 04/28/2008. I will be on vacation for a few days. If this is urgent please reach my Admin Kristine Smester ((917) 472-3387), otherwise I will respond to your message when I return.

1 0

Call for Contributions - Haskell Communities and Activities Report, May 2008 edition
by Janis Voigtlaender 25 Apr '08

25 Apr '08

Dear Haskellers, so much has happened in the Haskell world in the past months. Therefore, we would very much like to collect contributions for the 14th edition of the ================================================================ Haskell Communities & Activities Report http://www.haskell.org/communities/ Submission deadline: 10 May 2008 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) ================================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it to the us. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! * If you are interested in any project related to Haskell that has not previously been mentioned in the HC&A Report, please tell us, so that we can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming 6 months. If you have only recently been exposed to Haskell, it might be a good idea to browse the December 2007 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! As the purpose of the report is to collect recent or current activities, we encourage you to update all existing summaries and reports. We will probably drop any topics that have not had any activity for the past year, i.e., since May 2007, but we would very much prefer you to present an updated description of the topic. Of course, new entries are more than welcome. Reports should generally be kept brief and informative, ranging from a few sentences to a few hundred words, to keep the whole report reasonably sized. Looking forward to your contributions, Andres and Janis (current editors) FAQ: Q: Which topics are relevant? A: *All* topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports over distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we don't even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editors. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use it to write ``wishlist'' items for libraries and language features you would like to see implemented. Q: How much should I write? A: There's no formal limit. But generally, entries should be short and to the point. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. There also is no minimum length of an entry! The report aims at being as complete as possible, so please consider writing an entry, even if it's only a few lines long. Q: If I don't update my entry, but want to keep it in the report, what should I do? A: Tell us that there are no changes. We will reuse the old entry in this case, but we might drop it if it's older than a year, to give more room and more attention to projects that change a lot. Don't resent complete entries if you haven't changed them. Q: What format should I write in? A: The best format is a LaTeX source file, adhering to the template that's available at: http://haskell.org/communities/05-2008/template.tex There's also a LaTeX style file at http://haskell.org/communities/05-2008/hcar.sty that you can use to preview your entry. If you don't know LaTeX, then use plain text. If you modify an old entry, we will send you your old entry as a template within the next hours (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Don't worry about writing correct LaTeX, we will be able to handle your file. Please don't use HTML or even DOC. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

2 1

Terminal manipulation in windows?
by Jonathan Coveney 24 Apr '08

24 Apr '08

I have a program that requires the user to be in raw mode. This doesn't seem to be an issue on linux, but in Windows, it's a bit tricky (System.Posix.Terminal isn't an option). Is there a possible way to set this in Haskell? Or even outside of Haskell? It doesn't appear cygwin has a raw mode.

1 0