- Glasgow-haskell-users

Fwd: exposing hidden packages with runghc
by Iain Barnett 30 Jun '09

30 Jun '09

I think I posted this to the wrong list (libraries), so I've forwarded it here. ---- I'm trying to install HTTP-3000.0.0 (because I don't have cabal-install, and it's a dependency for cabal-install 0.4.9) This is on a Debian 5.1 machine with GHC 6.8.2 and 6.8.3 on it. The command: sudo runghc Setup configure -p && sudo runghc Setup build && sudo runghc Setup install The error: Could not find module `Data.Array.MArray': it is a member of package array-0.1.0.0, which is hidden ghc-pkg does list the hidden package. I've seen other threads on this "hiding" problem and searched through the GHC user guide, but I haven't actually found a solution, just explanation. I've tried sending the -package flag through to GHC by adding it to the runghc command, but I'm not doing this right, obviously. Would someone be able to point me in the right direction? It would be much appreciated. Iain

2 1

6.12.1 planning
by Simon Marlow 30 Jun '09

30 Jun '09

Hi Folks, As usual, we're planning a major release of GHC around September. Here's our list of the main items currently scheduled for 6.12.1, and their status. If you have the time and inclination to help with any of these, please get involved! * Parallel performance. 6.12.1 will ship with the improvements to parallel performance described in our ICFP 2009 paper. Still to do: overhaul the +RTS GC settings, tune for good performance by default. * Parallel profiling: the new RTS tracing features will be included, and we hope to have a release of ThreadScope to coincide with GHC 6.12.1. ThreadScope is written using gtk2hs, and could benefit from someone with expertise in producing polished gtk2hs apps - if you can lend a hand, contact Satnam Singh <satnams(a)microsoft.com>. * Unicode I/O: the new Unicode I/O library is in, and will ship with 6.12.1. Still to do: decide on the public API for changing encodings and newline conversion. * Shared libraries: we intend to ship with shared library support on at least x86/Linux and x86-64/Linux. There are various tasks remaining to do here - Duncan, can we have a summary? * Data Parallel Haskell. Manuel, can you comment on the state of play? What can we expect in time for 6.12.1? * Plugin support in GHC. The patches are not yet in GHC, and as far as I know are awaiting review - Simon, can you say more? * The new backend code generator. At the moment, it seems unlikely that GHC 6.12.1 will ship with the new code generator enabled by default, although it may well be available for testing. Meanwhile, work on it continues. The smaller items are all embodied in tickets, here are the tickets currently in the 6.12.1 milestone (135): http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… and on the 6.12 branch (251): http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… I estimate there are 2 man years of work here - needless to say, we aren't going to fix all these tickets :) As usual, if you want to vote for something, add your email to the CC field of the ticket. Several of these tickets would make good tasks for a fledgling GHC hacker. e.g. http://hackage.haskell.org/trac/ghc/ticket/2362 (allow full import syntax in GHCi) has a lot of support, and is a nice self-contained task (but not a small one). Even if you're not a GHC hacker you can still help, e.g. by helping to narrow down the cause of a bug, or verifying a bug on your platform. Let me remind people that GHC HEAD has the new build system, and it's actually rather pleasant to work with. Even if you have no idea what you're doing, you can always say 'make' at the top level and the build system will figure out what needs doing (ok, so that's what build systems are supposed to do, but GHC's has never quite managed it until now!). Cheers, Simon

3 2

Re: group keyword with TransformListComp
by Neil Mitchell 30 Jun '09

30 Jun '09

Hi, The question of syntax is always something that provokes intense discussion. My interest (and concern) with the choice of syntax in this case is three-fold: 1) I want HLint to turn on as many Haskell extensions as possible when parsing, with the trade off that they don't break a massive number of existing programs. For each extension I have weighed up the number of programs that will get broken (because the extension steals previously valid syntax), vs the number that will be parsed (how popular the extension is). I've erred on the side of enabling extensions, so am happy to accept changes in meaning for a!b and $(a). Almost all extensions get turned on, with the exception of TransformListComp, which even breaks the source code to HLint itself - something no other extension does. It seems the syntax stolen is far too much, especially when compared to other extensions. 2) I want to use TransformListComp in HLint. In particular, I have a nested pile of group/sort surrounding a list comp that would be perfect for TransformListComp. However, as it stands, I can't even enable the extension without that file breaking. I could qualify all the uses of group, but that seems too much hassle. I'd really like to enable the extension (without modification), and then start converting each group-like list-comp one at a time. 3) We'll never be able to make TransformListComp enabled in future versions of Haskell' since we break too many programs. It's an extension that is destined forever to remain only an extension. That seems like a lonely life for an extension. Thanks Neil On Sat, Jun 27, 2009 at 11:52 AM, Max Bolingbroke<omega.theta(a)gmail.com> wrote: > Hi, > > I agree this is annoying. It was hard to find syntax which was both > meaningful and currently unused, so we settled on this instead. As > Simon says, suggestions are welcome! > > Note that group *should* be parsed as a special id, so you can still > import D.L qualified and then use dot notation to access the function. > > Cheers, > Max > > > 2009/6/21 Neil Mitchell <ndmitchell(a)gmail.com>: >> Hi, >> >> The TransformListComp extension makes group a keyword. Unfortunately >> group is a useful function, and is even in Data.List. Thus, >> Data.List.group and TransformListComp are incompatible. This seems a >> very painful concession to give up a nice function name for a new >> extension. Is this intentional? Here's an example: >> >>> $ cat GroupKeyword.hs >>> {-# LANGUAGE TransformListComp #-} >>> module GroupKeyword where >>> >>> a = map head $ group $ sort [1..100] >>> $ ghci GroupKeyword.hs >>> GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help >>> Loading package ghc-prim ... linking ... done. >>> Loading package integer ... linking ... done. >>> Loading package base ... linking ... done. >>> [1 of 1] Compiling GroupKeyword ( GroupKeyword.hs, interpreted ) >>> >>> GroupKeyword.hs:4:15: parse error on input `group' >>> Failed, modules loaded: none. >>> Prelude> >> >> There are some places I'd like to use TransformListComp, but I often >> want to use group in the same module. >> >> Thanks >> >> Neil >> >

2 1

finalizers on handles
by Ganesh Sittampalam 29 Jun '09

29 Jun '09

Hi, I recently spent a while debugging a problem where a program deadlocked in the non-threaded runtime, but ran fine in the threaded runtime, despite the program having no blocking FFI calls, and boiled it down to the following test case: module Main(main) where import System import System.IO import System.Process main = do (ih, oh, _, _) <- runInteractiveProcess "cat" [] Nothing Nothing comphszp <- hGetContents oh print (length comphszp) -- hClose ih -- with this line they both deadlock The reason for the deadlock is fairly straightforward; since ih isn't closed before comphszp is fully demanded, no progress can be made. My guess is that the threaded runtime is fine because ih is dead at that point, and the finalizer for ih gets a chance to run, closing ih. If I'm right, is it really sensible for every handle to have this finalizer? Closing a pipe has externally visible side effects beyond just the release of resources, so it doesn't seem like it should happen non-deterministically. Cheers, Ganesh

4 11

How unique is a Unique?
by Matthijs Kooijman 29 Jun '09

29 Jun '09

Hi all, I've been doing some work with the GHC API, and I'm kind of confused as to how Uniques are supposed to work. I've found that each Name has a Unique that is its primary identification (at least for internal names). That means that two identifiers are different iff their Uniques are different, even when their OccNames are the same. This also means that two identifiers are equal when their Uniques are equal, even if their OccNames are different (though I think this situations is not supposed to exist and is really undefined?). Now, from the name "Unique", one would assume that each different identifier in a compiler run gets a different Unique, even when they are in different functions or modules. However, I've found some evidence to suggest otherwise. In particular, I've been looking at applying substitutions using CoreSubst. As a part of a substitution, the set of identifiers that are in scope are included with the substitutions to perform. I don't completely understand the requirements on this InScopeSet, but I do see that any identifiers that are bound in the to-be-substituted-in expression that are also in scope, will have their Unique changed. This makes sense when you want Uniques to be really unique, since \a_1 -> \a_1 -> \a_1 will then become \a_1 -> \a_2 -> \a_2. This does not sound related to substitution, but apparantly substition always performs this de-shadowing (as I think it's called?) implicitely. Giving this some further thought, it makes some sense, since when I'm performing the substituion \x_3 -> a_4 (which has a free variable a_4), on the expression \a_4 -> x_3, this must of course result in \a_5 -> a_4, not \a_4 -> a_4. So, it seems the InScopeSet should at least contain the free variables of the substited values. Looking a bit closer, this might be exactly what the definition at CoreSubst says: "Precisely, the in-scope set must be a superset of the free vars of the substitution range that might possibly clash with locally-bound variables in the thing being substituted in." I'm not completely sure what the "substituion range" is, but I can imagine this being the expression part of a binder -> expression substitution? Anyway, back to my original point. The above suggests that Uniques are not so unique after all. If every binder everywhere would get its own Unique, the Unique replacement CoreSubst does would never be neccesary. So, how is the uniqueness of Unique really defined? I can imagine that the generation of new Uniques is avoided as much as possible for performance reasons, and thus uniqueness is guaranteed only "on demand", by running deshadowing / substitutions when things could be clashing? Any thoughts on what kind of non-uniqueness is allowed and what is not? Are there common pitfalls when working with uniques? When to apply deshadowing or other uniqueness generating techniques? On a related note, is my understanding correct that deshadowing will only provide uniqueness on each "path" through the expression tree, and not over the entire tree? i.e., the expression let x_6 = \y_7 -> y_7; z_8 = \y_7 -> \y_7 in x_6 is a deshadowed expressions, even though both of the y_7 lambda binders refer to a different variable? If so, is there any function that gives complete uniqueness over an entire tree? Gr. Matthijs

2 3

group keyword with TransformListComp
by Neil Mitchell 27 Jun '09

27 Jun '09

Hi, The TransformListComp extension makes group a keyword. Unfortunately group is a useful function, and is even in Data.List. Thus, Data.List.group and TransformListComp are incompatible. This seems a very painful concession to give up a nice function name for a new extension. Is this intentional? Here's an example: > $ cat GroupKeyword.hs > {-# LANGUAGE TransformListComp #-} > module GroupKeyword where > > a = map head $ group $ sort [1..100] > $ ghci GroupKeyword.hs > GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > [1 of 1] Compiling GroupKeyword ( GroupKeyword.hs, interpreted ) > > GroupKeyword.hs:4:15: parse error on input `group' > Failed, modules loaded: none. > Prelude> There are some places I'd like to use TransformListComp, but I often want to use group in the same module. Thanks Neil

4 3

Re: Does this, and should this type check on GHC 6.10.x ?
by Ahn, Ki Yung 26 Jun '09

26 Jun '09

Tom Schrijvers wrote: > > Have you first, before you turn to GHC< considered whether this code > should be well-typed in any type system? > >> Review3.lhs:67:29: >> Could not deduce (Expandable (Tuple (Map ((,) t2) ys))) >> from the context (xs ~ t2 ::: ts2, Expandable t2) >> arising from a use of `:::' at Review3.lhs:67:29-59 > > At first sight, it looks like this constraint > > Expandable (Tuple (Map ((,) t2) ys)) > is indeed one that's required to hold in order to make the code > well-typed. Do you agree? > > Yet I see no instance of Expandable for Tuple. So why do you > think this constraint should hold anyway? I agree with you. I think the code is not supposed to type check, and that's what I experience from GHC so far. One problem that bothers us is that, as I mentioned in my original message, there were at least two reports that they were possible to type check in GHC, which we cannot reproduce. So, I'm just wondering what version and settings that makes it type check (if such version or setting exists, its good for GHC type system developers to be aware of it), and just double check if there is any other typing rules/theories that I am not aware of makes the code type check (if such version of GHC exists and it is not a bug). Another problem, which I haven't mentioned, I have when I tried to make additional type family instance declarations that latest (stable) distributions of GHC 6.10.x does not let me declare instances of (Expandable (Tuple (Map ((,) t2) ys))). When you try declaring such an instance something like this: > instance Expandable (Tuple (Map ((,) t2) ys)) where > ... GHC will give me an error message that type synonyms are not allowed in instance declarations: kyagrd@kyavaio:~/tmp$ ghci -fglasgow-exts -XUndecidableInstances Review3.lhs GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Review3.lhs, interpreted ) Review3.lhs:62:2: Illegal type synonym family application in instance: Tuple (Map ((,) t2) ys) In the instance declaration for `Expandable (Tuple (Map ((,) t2) ys))' Failed, modules loaded: none. So, my impression is that there is little hope even I try fixing this by adding more instance declarations, even if this was an incomplete code because of space restrictions of the review. But I still wanted to double check and discuss this matter with mailing list readers since there were few reports (which we fail to reproduce) that this type checks in their installation of GHC.

1 1

Does this, and should this type check on GHC 6.10.x ?
by Ahn, Ki Yung 26 Jun '09

26 Jun '09

Dear GHC type hackers, We got a code (please refer to the attached lhs file) that uses type families and type classes very cleverly. We don't know who wrote itbecause this was a contribution of an anonymous reviewer on our paper, which we are still revising. http://kyagrd.dyndns.org/wiki/SharedSubtypes Although we learned a lot from this code, we still have unsolved question about this code. The problem is, we are still not sure whether this code actually type checks in any GHC version, and we are not even sure whether this should type check or not as it is. I wasn't able to type check this in any of the GHC versions 6.10.1 on windows and debian linux, GHC 6.10.2 on windows and debian linux, or GHC 6.10.3 on debian linux. I also asked some of my colleagues at my school who has GHC installed to run this code, but they weren't able to load up either. However, some people we email conversation with reported that they were able to successfully load this code in GHC version 6.10.1 in their system. This is very surprising because we weren't able to type check it with the same version (GHC 6.10.1) on our machines (Windows XP and Debian Linux). Since there is no reason that GHC type checker would behave differently among different platforms, the code I am attaching is still an unsolved misery to us. It would be very helpful for us if any of can type check this successful could report what version of GHC on what platform and what GHC command line options used to make this code type check. And also, we welcome any discussion whether this code should or should not in principle type check. Thanks in advance, Ahn, Ki Yung FYI, I had the following error message when I tried it on ghc 6.10.3. (When I commented out the problematic line, the last equation of crossB, I was able to load it up though. So, this code definitely doesn't seem to be just thought out of one's mind without actually running on ghc.) ======================================================================== kyagrd@kyavaio:~/tmp$ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.10.3 kyagrd@kyavaio:~/tmp$ ghci -fglasgow-exts -XUndecidableInstances Review3.lhs GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Review3.lhs, interpreted ) Review3.lhs:67:29: Could not deduce (Expandable (Tuple (Map ((,) t2) ys))) from the context (xs ~ t2 ::: ts2, Expandable t2) arising from a use of `:::' at Review3.lhs:67:29-59 Possible fix: add (Expandable (Tuple (Map ((,) t2) ys))) to the context of the constructor `:::' or add an instance declaration for (Expandable (Tuple (Map ((,) t2) ys))) In the expression: Bs (mapB x ys) ::: crossB xs ys In the definition of `crossB': crossB (x ::: xs) ys = Bs (mapB x ys) ::: crossB xs ys In the definition of `expandPair': expandPair _ pair (a ::: as) (b ::: bs) = crossB (a ::: as) (b ::: bs) where crossB :: BList xs -> BList ys -> BList (Cross xs ys) crossB Nil ys = Nil crossB (x ::: xs) ys = Bs (mapB x ys) ::: crossB xs ys mapB :: (Expandable x) => Bit x -> BList ys -> BList (Map ((,) x) ys) mapB x Nil = Nil mapB x (y ::: ys) = pair x y ::: mapB x ys Failed, modules loaded: none.

3 2

question about -fno-pre-inlining
by John Lato 26 Jun '09

26 Jun '09

Hello, I was experimenting with compiler flags trying to tune some performance and got something unexpected with the -fno-pre-inlining flag. I was hoping somebody here might be able to clarify an issue for me. When compiled with -fno-pre-inlining, my test program gives a different result than compiled without (0.988... :: Double, compared to 1.0). It's numerical code, and was originally compiled with -fexcess-precision, however I have tried both with and without -fexcess-precision and the results are the same. The only other compiler flags in use are -O2 and --make. Is this expected behavior or a possible bug? I believe the value with -fno-pre-inlining is correct (and runs about 30% faster too). This was done on an OSX 10.5 Macbook with GHC-6.10.3. I could check this on some other systems if it would be helpful. Sincerely, John Lato

2 3

wiki page on GHC GC
by Bulat Ziganshin 24 Jun '09

24 Jun '09

i have started http://haskell.org/haskellwiki/GHC/Memory_Management - not much written yet -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 3