- Glasgow-haskell-users

Re: [Haskell-cafe] ANN: hp2html, a tool for viewing GHC heap-profiles
by Johan Tibell 21 Feb '12

21 Feb '12

Hi Iavor, On Mon, Feb 20, 2012 at 6:45 PM, Iavor Diatchki <iavor.diatchki(a)gmail.com> wrote: > Hello, > > I am happy to announce the availability of a little tool that I wrote while > I was doing some Haskell profiling. It converts GHC's heap-profiles into > HTML, and renders them nicely using the flot library. Its functionality is > similar to `hp2ps`. I wrote it because I find the HTML output easier to > work with and, also, because it can cope with partial profiles, so one can > refresh the profile while the program is running. The tool is a very short > Haskell program, so it should be quite easy to modify and improve (and there > is a lot that can be improved in it! :-). Looks really nice. The hovering behavior is nice, but I'd like to see the legend as well. It makes it quicker when you want to get a quick overview of what types there are, as the eye can travel back-and-forth between the graph and the legend. -- Johan

2 2

simple extension to ghc's record disambiguation rules
by John Meacham 20 Feb '12

20 Feb '12

Hi, I'd like to propose an extremely simple extension to ghc's record disambiguation rules, my motivation is that I often have record types with multiple constructors but common fields. so the handy idiom of f Rec { .. } = do blah return Rec { .. } won't work, because I don't know the specific constructor. so, my proposal is that when you come across something like (e::RecType) { blah = foo } (with an explicit type signature like shown) You interpret 'blah' as if it is a field of the record of type 'Rec'. This gives the advantages of record field names being scoped by type but without you having to specify the precise constructor. It is also backwards compatible for expressions, but would be a new thing for patterns which generally don't allow type signatures there. It sidesteps type checker interactions by only being triggered when an explicit type annotation is included. ideally it would be combined with the 'update' and 'label-based pattern-matching' extensions from this page http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords John

2 3

Holes in GHC
by Thijs Alkemade 19 Feb '12

19 Feb '12

Hello! As mentioned in our previous mail [1], we've been working on introducing Agda's holes into GHC [2]. Our general approach is as follows: we've added a hole to the syntax, denoted here by two underscores: "__". We've introduced a new HsExpr for this, which stores the hole's source span (as this is the only thing that a user needs to identify the hole). Then, we extended the local environment of the typechecker to include a mutable Map, mapping a SrcSpan to a Type and a WantedConstraints (we need these later to produce the correct class constraints on the type). In TcExpr.lhs, whenever the tcExpr function encounters a hole, it adds the source position with the res_ty and the current tcl_lie to the map. After type checking has finished, these types can be taken out of the map and shown to the user, however, we are not sure yet where to do this. Currently the map is read in tcRnModule and tcRnExpr, so loading modules and evaluating expressions with ":t" will show the types of the holes in that module or expression. There, we call mkPiTypes, mkForAllTys (with the quantified type variables we obtained from the WantedConstraints), we zonk and tidy them all (most of this imitates how tcRnExpr modifies a type before returning it, except the tidying, which needs to pass the updated TidyEnv to the tidying of the next hole). Examples: *Main> :t [__, ()] tcRnExpr2: [(<interactive>:1:2-3, ())] [__, ()] :: [()] *Main> :t map __ __ tcRnExpr2: [(<interactive>:1:5-6, a0 -> b), (<interactive>:1:8-9, [a0])] map __ __ :: [b] Any feedback on this design would be appreciated. We would like to know if this is something that could be considered to be added to GHC, and what your requirements for that are. Also, we have a confusing problem when type checking a module. Above, we showed the result of ":t map __ __" in ghci. However, if we put "f = map __ __" in a module, we get: tcRnModule: [(f.hs:1:9-10, GHC.Prim.Any * -> b), (f.hs:1:12-13, [GHC.Prim.Any *])] If I read GHC.Prim.Any * as forall a. a, then this is not correct: the GHC.Prim.Any * in both holes should have the same type. We assume it shows up because the type that should be there does not occur in the type signature of f (as it's just [b]), but so far we've been unable to figure out why this behavior is different in interactive mode. Does someone have an idea about what to do to avoid the introduction of these GHC.Prim.Any * types? Best regards, Thijs Alkemade [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021453.… [2] https://github.com/xnyhps/ghc/commits/master

15 26

Re: simple extension to ghc's record disambiguation rules
by Anthony Clayden 18 Feb '12

18 Feb '12

> Hi, I'd like to propose an extremely simple extension to > ghc's record disambiguation rules, > John, I've just posted a proposal on the 'Records in Haskell' wiki that I think will do the job for you. "Declared Overloaded Record Fields" (DORF). I'd appreciate feedback. > my motivation is that I often have record types with > multiple constructors but common fields. > This is exactly the use case I'm aiming at. > > so, my proposal is that when you come across something > like > > (e::RecType) { blah = foo } > > (with an explicit type signature like shown) > ... My proposal is the same, except that you don't need a type sig (or not always). That record syntax desugars to a call to `set', which is a method of class `Has' (which also has method `get'). Has/get/set are overloaded for each record/field combination. The instance is generated at the record declaration, instead of the H98 record selector function. > > It is also backwards compatible for expressions, but would > be a new thing for patterns which generally don't allow > type signatures there. > DORF is backwards compatible with H98 record selectors, in the sense that polymorphic selectors (using `get') are just functions. > It sidesteps type checker interactions by only being > triggered when an explicit type annotation is included. > (DORF uses usual instance resolution by record type and field.) > ideally it would be combined with the 'update' and > 'label-based pattern-matching' extensions from this page > http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords > > John > DORF supports update and pattern matching by label, per -XDismabiguateRecordFields and friends. Anthony

1 0

ghc 7.0.4 with the new Xcode 4.3
by Luca Ciciriello 17 Feb '12

17 Feb '12

Hi All. If you have ghc 7.0.4 on Mac OS X 10.7.3 and you have recently installed the new Xcode 4.3, here a workaround to continue using ghc without the /Developer folder (removed with Xcode 4.3). Workaround: from terminal type: sudo emacs /Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/bin/ghc-7.0.4 then insert your psw. in emacs change the line pgmgcc="/Developer/usr/bin/gcc" in pgmgcc="gcc" save all. Now Your ghc should be working properly. Bye. Luca.

1 0

Help me grok addFinalizer
by Michael Craig 17 Feb '12

17 Feb '12

When I read the docs for System.Mem.Weak, it all seems to make sense. But then this code doesn't run as I expect it to when I turn on -threaded: http://hpaste.org/63832 (Expected/actual output are listed in the paste.) I've tried this on 7.4.1 and 7.0.4 with the same results. Can someone enlighten me? Cheers, Mike Craig

6 7

recompilation on --main-is
by Conrad Parker 17 Feb '12

17 Feb '12

Hi, We have a project with around 200 Haskell source files, and around 20 executables which import these (as well as importing third-party libraries). We first build all the non-main files using a makefile generated with ghc -M. We then build the executables using a separate invocation of "ghc --make --main-is foo.hs", for each foo.hs. This worked fine with ghc-7.2.1; each final "ghc --make" would simply link the pre-built object files -- but with ghc-7.4.1 all these files are recompiled for each target executable. As a result our full build takes around 10-20x longer with ghc-7.4.1 than ghc-7.2.1. Looking at compiler/iface/FlagChecker.hs, it seems that the --main-is flag is used as an input to the recompilation checker. It would make sense that --main-is should force recompilation of the particular file that exports 'main', but it also forces recompilation of its dependencies. Is this a bug or is there a good reason to recompile everything? Conrad.

3 4

ANNOUNCE: GHC 7.4.1 Release Candidate 2
by Ian Lynagh 15 Feb '12

15 Feb '12

We are pleased to announce the first release candidate for GHC 7.4.1: http://www.haskell.org/ghc/dist/7.4.1-rc2/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect this to be the last release candidate, with the final release in approximately 1 week's time. Thanks Ian, on behalf of the GHC team

15 34

Re: Changes to Typeable
by Iavor Diatchki 14 Feb '12

14 Feb '12

Hello, On Mon, Feb 13, 2012 at 5:32 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > > There are fewer combinators from commonly used classes for working with > the left argument of a bifunctor, however. > I think that the bifunctor part of Bas's version is a bit of a red herring. What I like about it is that it overloads exactly what needs to be overloaded---the representation of the type---without the need for any fake parameters. To make things concrete, here is some code: > newtype TypeRepT t = TR TypeRep > > class Typeable t where > typeRep :: TypeRepT t > > instacne Typeable Int where typeRep = TR type_rep_for_int > instance Typeable [] where typeRep = TR type_rep_for_list The two formulations support exactly the same interface (you can define `Proxy` and the proxied `typeRep` in terms of this class) so I wouldn't say that the one is easier to use that the other, but I think that this formulation is slightly simpler because it avoids the dummy parameter to typeRep. -Iavor

3 2

Changes to Typeable
by Simon Peyton-Jones 14 Feb '12

14 Feb '12

Friends The page describes an improved implementation of the Typeable class, making use of polymorphic kinds. Technically it is straightforward, but it represents a non-backward-compatible change to a widely used library, so we need to make a plan for the transition. http://hackage.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable Comments? You can fix typos or add issues directly in the wiki page, or discuss by email Simon

10 24