- Haskell-Cafe - Haskell.org

Forward compatibility (was Re: [Haskell-cafe] GHCi infers a type but refuses it as type signature)
by Luke Palmer 24 Jun '09

24 Jun '09

On Tue, Jun 23, 2009 at 2:20 AM, <papa.eric(a)free.fr> wrote: > > Simple: the definition of MonadState uses those extensions. > > Thanks, yes it helps and explains all. :^) > > I suppose then that if -XFlexibleContexts is indeed required by the > standard libraries, it is a "safe" extension, meaning supported by all > compilers? Are many such extensions de-facto standard that anyone can enable > by default? You should treat "all compilers" the same way as a universal quantifier in mathematics. It's not just all the compilers you know about, but all possible compilers. In which case the answer to your question is of course no. (Beware: incoming my "recurring rant of the month", which I am trying ferociously to cram down the throats of my peers :-p) By measuring your software's portability on this stricter criterion, you contribute to the exponential growth of our field. It means that *every *future compiler can compile your code for 10% less effort*. *A future innovation may rely on one such compiler, which means it can use your code 10% sooner -- which may be the difference between your good code being used and it being badly reimplemented (and future bug fixes in the new code does not benefit yours). And so on, ad infinitum. When you think about potability, think about it from the perspective of twenty years in the future. Fundeps are becoming obsolete now, will your code still work when they are gone? Will it still work when the typeclass resolution algorithm is obsoleted by a superior algorithm (I'm looking at you, Oleg! :-)? When Haskell is obsolete, how hard will it be to port? Of course, there is definitely a place for extensions -- we should be testing them, to help refine the language that will one day obsolete Haskell. A culture of extension users helps us to know that, for example, even though implicit params are cool, nobody cares. I think "works on all existing compilers" is a fine definition of "portable" -- let's just realize that there is a level of portability beyond that, a level which gives our whole field a little boost. </rant> Luke

4 6

What happened to the installation chapter in the GHC User's Guide?
by Benjamin L.Russell 24 Jun '09

24 Jun '09

Up to GHC 6.10.2, there used to be an installation chapter in the GHC User's Guide (see "Chapter 2. Installing GHC" at http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/installing-bin-dist…) This section was very useful, for example, in determining whether it was possible to move the GHC tree around in Windows, or, by extension, whether it was necessary to uninstall GHC in order to install a later version. However, starting with GHC 6.10.3, this chapter seems to be missing. When I asked about this issue earlier on this mailing list a few months ago, IIRC, one response was that the chapter was outdated. Are there any plans to update this chapter? Every once in a while, I forget whether GHC needs to be uninstalled in order to be updated on Windows, and am forced to consult an earlier version of this chapter. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

2 1

Weird thing happened when I use gtk2hs with concurrent.
by Magicloud Magiclouds 24 Jun '09

24 Jun '09

This is the weird code, please see line 61. 20 cpuNew :: IO CPU 21 cpuNew = do 22 self <- meterNew 23 usage <- newIORef $ CPUusage 0 0 0 0 0 0 0 0 24 self `on` realize $ do 25 forkIO $ redraw self usage 33 return () 34 return self 35 where 56 redraw self usage = do 57 newUsage <- getUsage 58 oldUsage <- readIORef usage 59 postGUISync $ meterDraw self "Cpu" $ computeIdle $ diff newUsage oldUsage 60 writeIORef usage newUsage 61 threadDelay 10000 -- ten seconds, but it just refresh crazy! 62 redraw self usage

2 1

Using Parsec with ByteString ?
by Fernand 24 Jun '09

24 Jun '09

Hi, May be it's a frequently asked question, but I have been unable to find my way in the parsec-3.0.0 library when trying to write a small parser with Parsec that could work with ByteStrings. I mean, there is the Text.Parsec.ByteString module which allows to parse a file using ByteStrings, but the parser one needs to write must parse ByteStrings instead of Strings (that is, something like having a "Parsec Bytestring ()" type, unless I'm completely misunderstanding the situation). My problem is that I do not manage to write primitive parsing combinators (like string, satisfy, letter, etc.) to define my language's tokens. I'm surely missing some primitive somewhere (may be the Text.Parsec.Prim.token, though I do not really manage to use it). Thanks in advance, F.

2 2

Type system trickery
by Andrew Coppin 24 Jun '09

24 Jun '09

I have a datatype with about a dozen constructors. I'd like to find a way to use the type system to prevent one of the constructors from being used in certain places. But I can't think of a way to do that. data Foobar = Foo Foobar | Bar Foobar | Zoo Foobar I want the type system to track whether or not Zoo has been used in a specific value. Sure, you can check for it at runtime, but I'd be happier if the type system can guarantee its absence when required. I tried this: data Zoo x = Zoo x | NoZoo x data GeneralFoobar f = Foo f | Bar f type Foobar = GeneralFoobar Foobar type FoobarZ = GeneralFoobar (Zoo FoobarZ) but the type checker seems to not like it. (Plus I now have to wade through miles of NoZoo wrappers everywhere.) The other alternative is to just duplicate the entire data declaration, sans the Zoo constructor... but I'd obviously prefer not to have to do that. (E.g., if I ever need to alter the declaration, I now have two copies to keep in sync.) Suggestions?

8 17

(fwd) Haskell logo fail
by Benjamin L.Russell 24 Jun '09

24 Jun '09

On Tue, 16 Jun 2009 14:06:42 -0700 (PDT), in comp.lang.haskell Robert Hicks <sigzero(a)gmail.com> wrote: >http://blog.plover.com/prog/haskell/logo.html >From the site referenced at the above-mentioned URL: >Tue, 16 Jun 2009 > >Haskell logo fail >The Haskell folks have chosen a new logo. > ><image of new Haskell logo> > ><image of Amtrak logo> > >ouch The two logos do look disturbingly similar.... -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

6 6

How to determine if a FilePath is a directory name or regular file?
by Colin Paul Adams 24 Jun '09

24 Jun '09

I've been hoogling like bad to try to determine if a function like this exists. getDirectoryContents returns sub-directories as well as file names. I want only the latter, so I'm looking for a suitable filter. -- Colin Adams Preston Lancashire

9 15

Generate Fortran 77 parser from a yacc grammar using Happy
by Cetin Sert 24 Jun '09

24 Jun '09

I have stumbled upon the following F77 yacc grammar: http://yaxx.cvs.sourceforge.net/viewvc/yaxx/yaxx/fortran/fortran.y?revision… . How can I make a Fortran 77 parser out of this file using Happy<http://www.haskell.org/happy/> ? Why is there some C?/C++? code in that .y file?

2 1

HaRe (the Haskell Refactorer) in action - short screencast
by Claus Reinke 24 Jun '09

24 Jun '09

I've heard that many Haskellers know HaRe only as a rumour. It has been many years since the original project finished, and HaRe hasn't been maintained for quite some time, so just pointing to the sources isn't quite the right answer. The sources are still available, and build with GHC 6.8.3 (I had to fix one lineending issue on windows, iirc, and copy one old bug fix that hadn't made it into the latest release), but there is currently noone with the time or funding for maintenance, fixing bugs, making releases, or ironing out practical issues. If anyone would provide funding, people to do the work could be found, but the effort would probably be better spent on reimplementing the ideas in a GHC / Cabal environment (instead of the Haskell'98 environment targetted by our "Refactoring Functional Programs" project). If you've got the funding, please get in touch - even a three month run could get something started at least!-) In principle, the project experiences and lessons learned are quite well documented at the project site http://www.cs.kent.ac.uk/projects/refactor-fp/ but that doesn't give anyone an idea of what working with HaRe was like. With the recent interest in screencasts, I thought I'd make a little demo, for archival purposes. Nothing fancy, using only features that were already present in HaRe 0.3 (end of 2004), and not all of those, on a tiny 2-module example (screenspace is a bit crowded to keep the text readable on YouTube). I hope it might give a rough idea of what the papers, slides and reports are talking about, for Haskellers who weren't around at the time: http://www.youtube.com/watch?v=4I7VZV7elnY For the old HaRe team, Claus ------------------- YouTube video description: HaRe - the Haskell Refactorer (a mini demo) [4:10] The Haskell Refactorer HaRe was developed in our EPSRC project "Refactoring Functional Programs" http://www.cs.kent.ac.uk/projects/refactor-fp/ Building on Programatica's Haskell-in-Haskell frontend and Strafunski's generic programming library, it supported module-aware refactorings over the full Haskell'98 language standard. Interfaces to the refactoring engine were provided for both Vim and Emacs (this demo uses HaRe via GVim on Windows). While HaRe has continued to see occasional contributions by students and researchers, who use its Haskell program transformation API as a platform for their own work, it is not currently maintained. As the Haskell environment marches on, this demo is meant to record a snapshot of what working with HaRe could be like when it still built (here with GHC 6.8.3). The lessons learned (note, eg, the preservation of comments, and the limited use of pretty-printing, to minimize layout changes) are well documented at the project site, and should be taken into account when porting the ideas to the GHC Api, or other Haskell frontends.

3 2

GHCi infers a type but refuses it as type signature
by Eric 24 Jun '09

24 Jun '09

Hi haskell helpers, I am new to haskell (but enthusiast). I have begun to play with State and StateT, but this very simple exercice has led me to a strange situation where GHCi recognises and accepts the type of a function but GHC won't allow it as a type signature. Here is the example (which is also a try at literate haskell). > import Control.Monad.State > > type Play = Char > type Game = [Play] -- a game is a series of plays Now, you play by issuing a char, and you win if you have played an already played char. That was my first "play" function, returning True if you win. > play :: Play -> State Game Bool > play p = do ps <- get > put (p:ps) > return $ p `elem` ps I tested this one this way: > play_abc :: State Game Bool > play_abc = do play 'a' > play 'b' > play 'c' > > play_abca :: State Game Bool > play_abca = play_abc >> play 'a' Now in GHCi, "runState play_abc []" yields (False, "cba") "runState play_abca []" yields (True, "acba") Good! I was happy, now trying StateT to add IO to get console input: > type IOGame = StateT Game IO > > run_io :: IOGame Bool -> IO (Bool, Game) > run_io x = runStateT x [] Now I wanted a version of "play" that reads a char, on the following model: > play_once :: IOGame Bool > play_once = do x <- liftIO getChar > play' x Of course I first tried to express play' using play, and failed. Eventually I copied-and-pasted play, only changing the type signature, and it worked: > play' :: Play -> IOGame Bool > play' x = do xs <- get > put (x:xs) > return $ x `elem` xs Now, on GHCi I was happy to type: "run_io $ play_once" or even "run_io $ play_once >> play_once >> play_once" However, how to avoid the code duplication? I just tried to remove the type signature, and yes, play2 suddenly works in both State Game and StateT Game IO: > play2 x = do xs <- get > put (x:xs) > return $ x `elem` xs > > play2_abc :: State Game Bool > play2_abc = play2 'a' >> play2 'b' >> play2 'c' > > play2_once :: IOGame Bool > play2_once = do x <- liftIO getChar > play2 x So what's the type of play2? :t play2 yields: (MonadState [a] m, Eq a) => a -> m Bool Wow, nice, I get it now! However if I try to add that type signature, or even the second, more specific one below, ghci fails (signatures commented out because of that): > -- play3 :: (MonadState [a] m, Eq a) => a -> m Bool > -- play3 :: (MonadState Game m) => Play -> m Bool > play3 x = do xs <- get > put (x:xs) > return $ x `elem` xs It seems that an extension is required: Non type-variable argument in the constraint: MonadState [a] m (Use -XFlexibleContexts to permit this) In the type signature for `play3': play3 :: (MonadState [a] m, Eq a) => a -> m Bool So how is it possible that GHCi can infer (and use) a type that you cannot use as signature? And is it really non standard to avoid such code duplication? I was a bit surprised that such simple example should require a compiler extension. Thanks! Eric

3 2