June 2007 - Haskell-Cafe

type versus data declarations
by egallego＠babel.ls.fi.upm.es 08 Jun '07

08 Jun '07

Hello, I'm wondering why you can write > data FSet a = Show a => M (a -> Double) > > a :: FSet Double > a = M $ \x -> 0 and it works, but > type FSet a = Show a => (a -> Double) > > a :: FSet Double > a _ = 0 fails with > All of the type variables in the constraint `Show a' are already in scope > (at least one must be universally quantified here) > In the type synonym declaration for `FSet' If I understood the GHC manual, this should work, as FSet a should be replaced in a, so a type signature would come: > a :: Show a => (a -> Double) which is OK. Sorry if this is FAQ, but I did some searches and nothing came out. Thanks in advance, Emilio

3 6

Problem when class function doesn't mention all type parameters or...
by Daniil Elovkov 08 Jun '07

08 Jun '07

Hi again So, I keep trying to implement the dsl, I mentioned yesterday. I ran into a problem which can be illustrated by the following small example. > class Cl s1 a1 s2 a2 where > clF :: a1 -> a2 clF doesn't mention s1 and s2, they're used only to restrict types below > data T s a where > C :: (Cl s1 a1 s2 a2) => T s1 a1 -> T s2 a2 > f :: T s a -> a > f (C t) = let v = f t in clF v This doesn't typecheck with the error Could not deduce (Cl s11 a1 s2 a) from the context (Cl s1 a1 s a) arising from use of `clF' Here T depends on s, while the result of f doesn't. What happens is s gets lost. I'm not sure if the problem is that stated in the subject, really. But, I wonder how at all ghc should guess about s parameters. Maybe if f were T s a -> (s,a) where s were never evaluated... ...but no, this > f :: T s a -> (s,a) > f (C t) = let (s,v) = f t in (s,clF v) also fails to unify those s types. Can someone sched some light, please?

1 0

Re: I just don't get it (data structures and OO)
by Christopher Lane Hinson 08 Jun '07

08 Jun '07

> Let's say i have a deep nested data structure. > Universe containing galaxies, containing solar systems, containing > planets, containing countries, containing inhabitants, containing > ...whatever. Oh. I had /exactly/ this problem. If you use separate types (i.e. a newtyped integer, acting kindof like a pointer) to represent (1) the identity and (2) the state of the object, you can use a separate data structure that remembers which object is inside which other object. http://www.downstairspeople.org/darcs/unstable/roguestar-engine/src/Insiden… Where "InsidenessMap a b c" represents a relationship where b's are inside a's, and b's have a state of c. Then, you need to declare a separate InsidenessMap for each possible relationship, but this ensures that you'll never put a galaxy inside a solar system. Or you can make 'a' be a reference to any type of object; there are options. But, you just update this structure once, with no thought of recursively updating a heterogenous tree of data. It may not be the best solution, but if I knew of something better I would be using the better thing instead. --Lane

13 16

Parallelism and expensive calculations that may not be needed
by Felipe Almeida Lessa 08 Jun '07

08 Jun '07

Hello everybody! (Sorry if this is a newbie question, couldn't find the answer anywhere) Suppose I have an expensive function (such that even to be reduced to WHNF it takes a long processing time) > expensive :: Foo -> Maybe Bar and I want to calculate it on multiple processors, like in > calculate = parMap rnf expensive Well, fine. But suppose that then I give the result to a function like > final xs = reverse $ final' xs [] where > final' [] r = r > final' (x:xs) r = case x of Nothing -> [] > Just x -> final' xs (x:r) Given list :: [Foo], a sequential calculation as in > resultS = final $ map expensive list would not call expensive after finding a Nothing. But > resultP = final $ calculate list will keep calculating all the other expensive's because they were sparked? Also, suppose that in list there are thousands of elements, whereas the last one is the only x such as "expensive x == Nothing". More importantly, calculating "expensive x" is very fast for some reason. In both versions above, all the initial elements will have to be calculated in order to find that the last one (that probably was already computed in the parallel version) was Nothing and that all the work must have to be thrown away. Are the observations above valid? Is there a way to improve this style of computation? Any pointers are appreciated =). I think that to solve the second problem, I needed some sort of fold that is aware of parallel nature of the list and that folds on the order in that the thunks get evaluated, and not on order of the list. But I guess it's not possible to write something like this, right? Cheers, Felipe. -- Felipe.

2 3

Re: [Haskell] ANN: Catch (first ever release)
by Neil Mitchell 08 Jun '07

08 Jun '07

Following up on haskell-cafe: Hi Chris, > > For the last few years I've been working on a pattern-match checker > > for Haskell, named Catch. I'm now happy to make a release: > I would love to use this with regex-tdfa (and the other regex-* modules). > > At the moment regex-tdfa is uses a few extensions such as recursive "mdo" > notation and parts hook up to the MPTC + fundeps used in regex-base. The > MPTC+fundeps are not part of the workhorse modules, they are just "type class > syntactic sugar" that makes it easier for the library consumer. But "mdo" _is_ > used in two of the important internal functions. You have several options: * Wait until GHC Core is working, when Catch will work with all these things automatically. * Rewrite your code to eliminate mdo, if you wish to port regex to Yhc you will need to do this anyway. * Find an mdo preprocessor (I think one exists?) and preprocess the code before checking. Obviously the GHC Core one is least work for you, but won't be available for a while. Thanks Neil

1 0

HopenGL
by Ruben Zilibowitz 08 Jun '07

08 Jun '07

Hi, If anyone knows how to get HOpenGL to draw coloured lines, I'd like to know. Currently I can draw coloured objects like planes cylinders or spheres, but not lines. Lines always seem to appear black. Regards, Ruben

4 5

haskell wiki indexing
by Vincent Kraeutler 08 Jun '07

08 Jun '07

as was pointed out on the programming reddit [1], crawling of the haskell wiki is forbidden, since http://www.haskell.org/robots.txt contains User-agent: * Disallow: /haskellwiki/ and indeed, a google search gives the old wiki http://www.google.ch/search?q=haskell+wiki i.e. http://haskell.org/hawiki/FrontPage rather than http://haskell.org/haskellwiki/Haskell in other words, it seems like the most relevant search engines do not index the haskell wiki. i have reported this on #haskell about a week ago[2], and this setting was acknowledged to be a measure deliberately taken to curb excessive load from spiders crawling the wiki. i still believe this a highly harmful stance, and just to make sure that whoever may feel concerned is at least aware of the problem, i am now cross-posting to this list as well. kind regards, v. [1] http://programming.reddit.com/info/1qzjx/comments/c1r3ok [2] http://tuukka.iki.fi/tmp/haskell-2007-05-16.html

9 11

ghc wiki registration failure ( was: Failure in GHC compilation)
by Daniil Elovkov 08 Jun '07

08 Jun '07

Hi I wanted to add a couple of words that another solution would be to add an option to xargs in target.mk xargs -n NNN where NNN is less than the OS limit. (That helped me to build LambdaVM on windows, there are quite a lot of class files there, and no SPLITOBJS will obviously help) Editing target.mk isn't a good thing, probably. Maybe some $XARGSOPTS could be introduced... BUT trying to register on the wiki resulted in an error with this python traceback Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/trac/web/cgi_frontend.py", line 131, in run dispatch_request(req.path_info, req, env) File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch resp = chosen_handler.process_request(req) File "build/bdist.linux-i686/egg/acct_mgr/web_ui.py", line 117, in process_request File "build/bdist.linux-i686/egg/acct_mgr/web_ui.py", line 138, in _do_create File "build/bdist.linux-i686/egg/acct_mgr/api.py", line 88, in set_password File "build/bdist.linux-i686/egg/acct_mgr/htfile.py", line 50, in set_password File "build/bdist.linux-i686/egg/acct_mgr/htfile.py", line 85, in _update_file IOError: [Errno 13] Permission denied: '/srv/trac/ghc/trac.htpasswd' 2007/6/4, Simon Peyton-Jones <simonpj(a)microsoft.com>: > I've extended the "what to look for if your build fails" section in > http://hackage.haskell.org/trac/ghc/wiki/Building/Windows > > Please do keep adding to this page! Every time you trip over something, think about whether your experience could be used to help someone else. > > Simon > > | -----Original Message----- > | Wrom: KEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJ > | Ilari Vuokko > | Sent: 02 June 2007 21:09 > | To: Monique Monteiro > | Cc: haskell-cafe(a)haskell.org > | Subject: Re: [Haskell-cafe] Failure in GHC compilation > | > | Hi, > | > | On 6/2/07, Monique Monteiro <monique.louise(a)gmail.com> wrote: > | > has anyone any idea about what may cause the following error in GHC > | > compilation? > | > | It's exactly what it says...too long argument list (it's limited in Windows.) > | This is usually caused by having split-objs on, which causes *a lot* of object > | files being generated, all of them passed to ar or ld. > | > | > c:\ghc\ghc-6.6.1\bin\ar.exe: creating libHSbase.a > | > xargs: c:/ghc/ghc-6.6.1/bin/ar: Argument list too long > | > make[2]: *** [libHSbase.a] Error 126 > | > make[2]: *** Deleting file `libHSbase.a' > | > Failed making all in base: 1 > | > make[1]: *** [all] Error 1 > | > make[1]: Leaving directory `/cygdrive/c/GHC6.6.1/ghc-6.6.1/libraries' > | > make: *** [stage1] Error 2 > | > | Untested: setting SplitObjs=NO in build.mk might help (as there will be less > | object files to pass to ar. > | > | If ghc head is already using cabal, this problem is solved there. > | > | It might also be possible to extend ghc build machinery to pass parameters > | in file for ar and ld - but that requires new enough mingw toolchain. > | > | HTH, > | Esa > | _______________________________________________ > | Haskell-Cafe mailing list > | Haskell-Cafe(a)haskell.org > | http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

OK, so this VIM thing -- how do I make it actually work?
by Michael T. Richter 08 Jun '07

08 Jun '07

I've given up on getting a decent text editor for editing Haskell (specifically literate Haskell -- plain Haskell works fine in GEDIT). Instead I fire up VIM and get ... a total mess. At first I think maybe I've screwed up a whole bunch of settings or something, so I nuke everything in my home directory that begins with .vim and then, for added measure, head over to /usr/share and nuke the entire ./vim directory tree. I then reinstall vim (from the Ubuntu Edgy archives) to get a brand new set of config files unsullied by my hands. I still get a dog's breakfast. A screen shot of what I'm seeing with a representative example of a .lhs file to show what I mean can be found at http://img357.imageshack.us/img357/5798/gvimexamplezv4.png. (I've pared it down to the minimum I could find that shows the behaviour clearly.) The problems I'm seeing are the ugly white-on-red for underlines, the lack of any kind of differentiation for keywords/operators/etc. vs. identifiers (although some punctuation is recognized, specifically curly braces), comments not being noted, etc. Basically it looks like the Haskell is simply not being recognized at all (and, if the @saBinds@ thing is what I think it is, it looks like some latex isn't being recognized fully either). Can anybody vim-centric please take a look at this and give me a few educated guesses as to what is happening here? For good measure, here's the beginning of the lhaskell.vim file that comes with my vim distribution (7.0 in the Ubuntu archives). If it's desired I can attach the whole file. (It isn't actually all that large.) " Vim syntax file " Language: Haskell with literate comments, Bird style, " TeX style and plain text surrounding " \begin{code} \end{code} blocks " Maintainer: Haskell Cafe mailinglist <haskell-cafe(a)haskell.org> " Original Author: Arthur van Leeuwen <arthurvl(a)cs.uu.nl> " Last Change: 2004 Aug 31 " Version: 1.01 " " Thanks to Ian Lynagh for thoughtful comments on initial versions and " for the inspiration for writing this in the first place. " " This style guesses as to the type of markup used in a literate haskell " file and will highlight (La)TeX markup if it finds any " This behaviour can be overridden, both glabally and locally using " the lhs_markup variable or b:lhs_markup variable respectively. " " lhs_markup must be set to either tex or none to indicate that " you always want (La)TeX highlighting or no highlighting " must not be set to let the highlighting be guessed " b:lhs_markup must be set to eiterh tex or none to indicate that " you want (La)TeX highlighting or no highlighting for " this particular buffer " must not be set to let the highlighting be guessed " " " 2004 February 18: New version, based on Ian Lynagh's TeX guessing " lhaskell.vim, cweb.vim, tex.vim, sh.vim and fortran.vim " 2004 February 20: Cleaned up the guessing and overriding a bit " 2004 February 23: Cleaned up syntax highlighting for \begin{code} and " \end{code}, added some clarification to the attributions " -- Michael T. Richter <ttmrichter(a)gmail.com> (GoogleTalk: ttmrichter(a)gmail.com) It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it. (Steve McConnell)

12 17

Scope of type variables in associated types
by Matthew Sackman 08 Jun '07

08 Jun '07

The following doesn't seem to work. Is this a limitation of the current implementation or will it never work? Are there any work arounds without introducing extra type params into the data type E? > class G a b | a -> b where > data E a :: * > wrap :: b -> E a > unwrap :: E a -> b > instance G a b where > data E a = EC b -- this line - the b is not in scope. > wrap = EC > unwrap (EC b) = b I get "Not in scope: type variable `b'". I was rather hoping it would be in scope. I've tried: > instance forall a b . G a b where > ... but that doesn't seem to extend the scope as it does with functions. I realise this is bleeding edge stuff. But I can't seem to work out from the various wiki pages on this whether this is going to be eventually supported. This is all with today's GHC HEAD. Cheers, Matthew -- Matthew Sackman http://www.wellquite.org/

7 14