June 2009 - Glasgow-haskell-users

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

Strangeness in the syntax of types
by Niklas Broberg 23 Jun '09

23 Jun '09

Hi all, I've had a curious bug report [1] for haskell-src-exts, pointing to a difference in behavior between haskell-src-exts and GHC. Digging further, it seems to me like GHC is behaving quite strange in this instance, but since we don't have formal documentation for the extensions I can't be sure. I'm *almost* convinced this is a bug in GHC, but with these type extensions I can never be quite sure. Thus I'm putting it out here in the hope that someone will either explain why it is this way, or tell me to go file a bug report. The gist of it is the following piece of code: > multipleCtx :: Eq a => Show a => a > multipleCtx = undefined GHC accepts this code, while haskell-src-exts requires parentheses around the latter part of the signature, i.e. Eq a => (Show a => a). The difference is the following productions haskell-src-exts: > ctype :: { PType } > : 'forall' ktyvars '.' ctype > | context '=>' type > | type GHC: > ctypedoc :: { LHsType RdrName } > : 'forall' tv_bndrs '.' ctypedoc > | context '=>' ctypedoc > | gentypedoc Notice GHC's recursive call to ctypedoc after the =>. I have no idea what the doc suffix on the production is intended to indicate though - and I was curious to find a separate set of rules that don't have that suffix: > ctype :: { LHsType RdrName } > : 'forall' tv_bndrs '.' ctype > | context '=>' type > | type This one looks just like the one that haskell-src-exts uses - type instead of ctype after the =>. So what's the difference between the two in GHC? Looking further, the former is used in top-level type signatures, while the latter is used for pretty much everything else. In particular, you can't put a ctypedoc inside parentheses, there you would have to use ctype. So while GHC accepts the above definition, it rejects e.g. the (seemingly) equivalent > multipleCtx :: (Eq a => Show a => a) > multipleCtx = undefined My guess would be that there's a bug here, and that it's the recursive call to ctypedoc that is at fault, it should really be gentypedoc. On the other hand there's no problem parsing either, so there's no technical reason not to allow chained contexts without parentheses, even though I personally think it looks quite awkward. Enough rambling - can someone make me the wiser? Cheers, /Niklas [1] http://trac.haskell.org/haskell-src-exts/ticket/37

3 3

Re: was 6.10.3 prerelease
by Christian Maeder 22 Jun '09

22 Jun '09

Maybe a binary distribution for Mac OS Tiger would be useful. (I prefer the plain .tar.gz files over .pkg, because they don't require root rights.) I usually make them using a file mk/build.mk containing: BIN_DIST=1 Project=Ghc HADDOCK_DOCS = YES #XMLDocWays = html using the commands: ./configure make make binary-dist I can offer binary dists for x68 under Solaris and PPC Mac OS 10.5 (Leopard), the latter depending on: /opt/local/lib/libiconv.2.dylib /opt/local/lib/libncurses.5.dylib /opt/local/lib/libgmp.3.dylib Cheers Christian http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… Yusaku Hashimoto wrote: > It is problem about the library for dealing OS process. This bug is > fixed, and fixed version of process is in the repository. You can check > out latest library from http://darcs.haskell.org/packages/process and > replace the library in the build directory (libraries/process). > > If you are bothered to this, you can just comment-in a line 90 (maybe > near of here...) in libraries/process/cbits/runProcess.c to > disableItimers() in the child process. > > HTH, > Hashimoto > > On 2009/06/20, at 21:09, Iain Barnett wrote: > >> In reference to http://www.nabble.com/6.10.3-prerelease-td23346957.html >> >> I also run Mac OSX 10.4.11 (there are some left) and I experience the >> same problem but with the full release of 6.10.3 from source. I've >> read the discussion and the trac ticket at >> http://hackage.haskell.org/trac/ghc/ticket/3243, but I have no idea >> how to actually get and apply the patch. >> >> Sorry if I'm being incredibly thick, (or even just a bit thick) but I >> have barely used C or darcs (though I do have darcs installed). Any >> advice on how to fix this is much appreciated - originally I just >> wanted to upgrade Cabal but when it didn't work I tried to upgrade >> GHC, and now I seem to be digging a big hole! >> >> Iain >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

was 6.10.3 prerelease
by Iain Barnett 20 Jun '09

20 Jun '09

In reference to http://www.nabble.com/6.10.3-prerelease-td23346957.html I also run Mac OSX 10.4.11 (there are some left) and I experience the same problem but with the full release of 6.10.3 from source. I've read the discussion and the trac ticket at http:// hackage.haskell.org/trac/ghc/ticket/3243, but I have no idea how to actually get and apply the patch. Sorry if I'm being incredibly thick, (or even just a bit thick) but I have barely used C or darcs (though I do have darcs installed). Any advice on how to fix this is much appreciated - originally I just wanted to upgrade Cabal but when it didn't work I tried to upgrade GHC, and now I seem to be digging a big hole! Iain

1 0

build question: ghc 6.11.20090605 -> ghc 6.10.3?
by Uwe Hollerbach 19 Jun '09

19 Jun '09

Hi, all, is it expected that a snapshot version (I'm using 2009.06.05) should be able to build the released version 6.10.3? This weekend I tried the "porting to an unsupported machine" procedure with the aforementioned snapshot version; that worked, after some fussing, and I seem to have a working ghc install, including several libraries and cabal. But I tried building the Haskell Platform, and it warns (rightly, as it turns out) about this being an unsupported version of ghc. So I'd like to get onto the regular release train, as it were, and transfer myself to ghc 6.10.3. But that fails to build, after a while. Specifically, it goes until it's trying to compile the stage1 version of ghc/Main.hs, and then it complains that it can't find the file "../includes/ghcautoconf.h". Now, that file does exist; but it looks like it's being referenced from HsVersions.h, which lives in the lib/ tree of the installed snapshot compiler, and relative to the location of that file, there is indeed no such path. Is that a bug? If I create the includes directory where HsVersions.h appears to be seeking it, and add in ghcautoconf.h from where it got created during the setup of ghc 6.10.3, the build proceeds (a little) further, but it still dies. thanks... Uwe PS I suppose I should describe in a little bit of detail what I did for the porting, might be useful for someone else trying this. It was a rather vanilla port, x86_64-unknown-linux to same; my target machine is my workstation at work, where I don't have root, and I do have permission from IT to install this stuff, but no support... so they won't install rpms for me, or anything like that. It's also a slightly old and somewhat customized version of some RedHat corporate release, so recent plain-vanilla tarballs didn't work... hence the need to port. So: first problem was that my target machine identified itself as x86_64-unknown-linux-gnu; note the 4-part identifier, rather than the 3-part that's more usual. That confused the configure scripts... I had to hack up configure.ac to force it to see itself as x86_64-unknown-linux. First problem solved... After that, the back-and-forth of the various derived files was tedious but straightforward, and stuff built well. The second problem was that the command listed on the ghc porting page, "for c in libraries/*/configure; ...", is specific to bash or sh, and my workstation runs tcsh. No problem, I knew what to do, but it might be an issue for someone who doesn't know. The third issue was the sed syntax on the same page: the version of sed that I was using didn't like the space between the "-i" and the ".bak". I don't know if that's a variation from one version of sed to another, or a typo on the page, or??? Again no big deal, the error message from sed was informative enough for me to figure out what to do. The fourth issue was that the "make all_ghc_stage2" command failed: the linker complained that it couldn't find the hs_main symbol. I found that in RtsMain.o, and manually added that object file to the appropriate (?) library; then it worked. I'm not actually sure that I got the actually-most-correct library, but... it didn't seem to break anything. After that, it went through ok. I checked that that stage2 compiler could indeed build a working executable from haskell sources, that was ok, and then I rebuilt that snapshot from scratch using that compiler. That worked fine, and after that the various libraries needed to get cabal up and running were straightforward.

2 1