- Glasgow-haskell-users

signals and GHC 6.10
by John Meacham 09 Jul '09

09 Jul '09

I noticed that programs compiled with GHC 6.10 seem to be eating signals and exiting with an error code of 255, rather than the proper exit code for the signal that killed the process. I can understand that the GHC runtime may need to perform some cleanup on a SIGINT or other signal, but instead of doing an exit after catching it, could it be modified to restore the original handle (which may be none) and reraise the signal via kill(getpid(), sig)? This is much friendlier and standard behavior and will also ensure any chained signal handlers are run properly. (in addition to giving proper exit codes). John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

2 2

GHC API: How to determine Type.Type equality when using type operators?
by Christiaan Baaij 09 Jul '09

09 Jul '09

Hi all, I've been doing some work with the GHC API where I translate Haskell to VHDL, and as such I have to translate Haskell Types to VHDL Types. I store the translations in a Map as such: -- A orderable equivalent of CoreSyn's Type for use as a map key newtype OrdType = OrdType { getType :: Type.Type } instance Eq OrdType where (OrdType a) == (OrdType b) = Type.tcEqType a b instance Ord OrdType where compare (OrdType a) (OrdType b) = Type.tcCmpType a b -- A map of a Core type to the corresponding type name type TypeMap = Map.Map OrdType (AST.VHDLId, Either AST.TypeDef AST.SubtypeIn) This solution work fine for 'simple' types and ensures that the VHDL Type definitions are all unique. However, a problem rises when type operators come in to play, as Type.tcEqType does not know the 'rules' of these type operators and can thus not infer that two types are equal. Let me give some context for my problem: We use statically fixed-size vectors instead of lists, as we always want to know the static length of an array. We use a vector implementation similar to Data.Param.FSVec defined in the parameterized-data package [1], except that we use type-level integers from the tfp library [2] to define the static vector lenght. The tfp library support things like type-level multiplication, something that we use in our vector library. Now, say we have two bit vectors of length 12 defined as such: a :: Vector D12 Bit b :: Vector (D3 :*: D4) Bit The GHC type checker can infer that 'a' and 'b' are of equal type, as it knows the definitions for the ':*:' multiplication type-operator that is defined in the tfp library. Of course, the only answer Type.tcEqType can give us if we ask if the types of 'a' and 'b' are equals is False, as it does not know the context provided by the type-operator. So my question is: Is there a functions in the GHC API that I can use to check the equality of two types given the context provided by certain type operators? I have looked at the Haddock documentation, the GHC Wiki, and the GHC code itself, but have been unable to find such a function. Regards, Christiaan [1] http://hackage.haskell.org/package/parameterized-data [2] http://hackage.haskell.org/package/tfp

3 3

6.10.4-pre test
by Serge D. Mechveliani 06 Jul '09

06 Jul '09

Dear GHC developers, I have tested ghc-6.10.3.20090628 on Debian Linux, i-386-kind machine. There were only two tests: 1) making from source by itself 2) making DoCon and running its test (without profiling). It looks all right. With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

How to save a haskell data structure in C?
by Shu Wu 03 Jul '09

03 Jul '09

Hey, folks. I've got a problem which I've thought about for days. I need to write a program that mixes C and haskell code. And the C code controls the procedure. In C code, I want to save a complex data strcuture defined in haskell and pass it back to a haskell function at certain time. Like the following: in haskell: data A = A {...} -- very very complex data structure initA :: A initA = A {...} func :: A -> A func a = ... -- return a new 'A' in C: main { a = initA ... take some actions a = func a; ... take some other actions a = func a; ... ... } Different from most cross-language programs, this C program doesn't alter the data in haskell, just saves it and passes it on. So I'm wondering if there's some convienent way other than marshalling the data in haskell? BTW, mashalling data requires all work done in IO monad, which will change the program stucture. So I really don't want to mashal it. Thank you!

2 1

better generation of vi ctags in ghci
by Peter Hercek 02 Jul '09

02 Jul '09

Hi GHC and VI users, I got frustrated with vi tags not working after some unrelated code is edited in a source file. Moreover non-exported top level declarations were not available in vi tags file. Here is an attempt to fix it: http://www.hck.sk/users/peter/pub/ghc/betterCTags.patch Why would you want the new implementation of :ctags ghci command? * Tags are searched based on the line content. This is what Exuberant Ctags do for other languages and it is the other posix way to do it. This makes the positioning to work well even when the source code was edited (on places unrelated to the tag location). More complicated Ex statements can be used to improve it even more but then it does not work well with :tselect (it screws up tag kinds, at least with my version of vim 7.2.65). * All top level symbols defined in a module are added to the tags file. Even the non-exported ones. These are marked as static (file:) so the default tag selection (Ctrl-]) works fine based on the file you started the search from. * Tags get kinds added so you can select whether you want to get to a type constructor or a data constructor (that is if you share names between the two). * In general it is a nice addition to vim haskellmode. If you search for help on symbols in libraries then opening haddock is cool. If you search for help on a symbol in your project then opening the tag in a preview window (Ctrl-W} or ptselect) is cool. Problems: * It needs somebody to check that emacs tags were not broken. I'm not an emacs user but some tag generation code is shared for vim and emacs. I tried to keep emacs tags exactly the way they were (only the exported symbols, original file format). * If your code happens to have definitions on lines which happen to exist more times in one source file then it may put you at an incorrect location. I doubt it will ever happen but if anybody thinks it is really bad we can keep the original format of vim tags too. Then e.g. :ctags would generate tags with line numbers and :ctags! would generate tags with search expressions. If there is any support for this and ghc team decides to merge it I can provide darcs patch. I can do changes needed to get it merged. Peter.

3 5

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