November 2000 - Glasgow-haskell-users

RE: getting type information about local bindings
by Simon Peyton-Jones 10 Nov '00

10 Nov '00

Don't try to get the type environment out. Instead, look at the syntax tree produced by the type checker. Each binder is an Id. There's a function idType :: Id -> Type that tells you the type of each binder. Quite how you present it to the user in a good way isn't clear to me, Simon | -----Original Message----- | From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU] | Sent: 10 November 2000 05:56 | To: glasgow-haskell-users(a)haskell.org | Cc: bjpop(a)cs.mu.OZ.AU | Subject: getting type information about local bindings | | | Hi all, | | In GHC 4.09 the flag "-ddump-types" causes the type signatures of | top-level bound identifiers to be printed. | | I would really like to make use of the type-checker in GHC, | however, I would | also like to obtain the types of locally bound identifiers | (things in let expressions and where clauses). Obviously | there is going to | be some trickery regarding type variables from enclosing scopes. | | I looked in the TcModule.lhs module and noticed that the TcResults | value returned by typecheckModule contains a value | environment that only | specifies the types of top bound identifiers. | | Further investigation of the code led me to the TcBinds.lhs module | and the tcBindsAndThen function. I can see that local type | environments | are not passed upwards during type checking/inference. | | At some point I got lost in the code. Does anyone know of a | reasonable means | for obtaining this type information? I don't mind doing some | hacking, but | I wanted to get advise from the experts as to whether I might | be wasting | my time. | | Perhaps such a thing is done somewhere when generating Core code? | | As an aside I dare say that such an extension would be useful | to other | people, particularly those writing source transformation code. | | Regards, | Bernie. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

getting type information about local bindings
by Bernard James POPE 10 Nov '00

10 Nov '00

Hi all, In GHC 4.09 the flag "-ddump-types" causes the type signatures of top-level bound identifiers to be printed. I would really like to make use of the type-checker in GHC, however, I would also like to obtain the types of locally bound identifiers (things in let expressions and where clauses). Obviously there is going to be some trickery regarding type variables from enclosing scopes. I looked in the TcModule.lhs module and noticed that the TcResults value returned by typecheckModule contains a value environment that only specifies the types of top bound identifiers. Further investigation of the code led me to the TcBinds.lhs module and the tcBindsAndThen function. I can see that local type environments are not passed upwards during type checking/inference. At some point I got lost in the code. Does anyone know of a reasonable means for obtaining this type information? I don't mind doing some hacking, but I wanted to get advise from the experts as to whether I might be wasting my time. Perhaps such a thing is done somewhere when generating Core code? As an aside I dare say that such an extension would be useful to other people, particularly those writing source transformation code. Regards, Bernie.

1 0

ppr for Haskell Abstract Syntax
by Kate S. Golder 07 Nov '00

07 Nov '00

Hi - I was wondering if anyone knows if there is a pretty printer for Haskell Abstract Syntax anywhere? I've been asking around, but haven't located one yet. If you know of one that I could use, it would be really helpful! Thanks in advance, *Kate ********************** Kate S. Golder Wellesley College Class of 2002 Freeman Hall Wellesley College Wellesley, Ma 02481

2 1

New InstallShield
by Reuben Thomas 06 Nov '00

06 Nov '00

Yet another improvement to the GHC 4.08.1 InstallShield. Thanks to Christian Lescher and Sigbjorn Finne, various bugs have been fixed to do with DLL building, so both static DLLs (where all the haskell stuff is linked in) and dynamic DLLs (where the DLL you build is dependent on the GHC DLLs) work rather better. Also, thanks to Martijn Schrage for pointing out that I'd omitted the net hslib from the InstallShield. It's there now. -- http://sc3d.org/rrt/ | certain, a. insufficiently analysed

1 0

RE: fatal error: heapCensus
by Simon Marlow 03 Nov '00

03 Nov '00

> unfortunately I forgot to ask my questions ;o) > > What does heapCensus mean ? It's an internal error in GHC's heap profiler, and indicates a bug somewhere. Could you send us the code? Cheers, Simon

1 0

RE: My mistake is harder to diagnose than it could be
by Simon Peyton-Jones 02 Nov '00

02 Nov '00

In the new GHCi system we plan to make it *required* that the module name and the file name match, EXCEPT for module Main. This seems to remove a whole class of errors. Yell if that'll be problematic for you Simon | -----Original Message----- | From: qrczak(a)knm.org.pl [mailto:qrczak@knm.org.pl] | Sent: 18 August 2000 19:45 | To: glasgow-haskell-users(a)haskell.org | Subject: My mistake is harder to diagnose than it could be | | | I've just done the same mistake a third time: took a module A, moved | part of it to a new module B, imported A from B, but forgot to change | the module header in B which still said "module A". | | The GHC's answer to that when compiling B.hs is that the module A | does not export a bunch of things (if listed explicitly in import), | or that they are not found at all (if imported the whole A). Things | that are easily seen exported from A.hs - strange that I was wondering | again what's going on. | | GHC should warn when a module imports itself. Or warn about mismatches | between the module and file name except Main. Or whatever - | the current | error message is not very helpful. | | -- | __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ | \__/ | ^^ SYGNATURA ZASTEPCZA | QRCZAK | |

1 0

fatal error: heapCensus
by Oliver Braun 02 Nov '00

02 Nov '00

Dear GHC-Users, I am currently developing part of the EdComb library (http://ist.unibw-muenchen.de/EdComb/) I have compiled all files with the -prof and the -auto-all flag. When starting the program * without any RTS options -> everything is OK * with +RTS -p -> everything is OK * with +RTS -h -> fatal error: heapCensus I am using GHC version 4.08.1 on a Debian/GNU Linux Box, installed with the newest Debian packages from http://www-i2.informatik.rwth-aachen.de/Software/Haskell/debian. Olli -- Federal Armed Forces University Munich Tel. 089 - 60190686 Werner-Heisenberg-Weg 102/128 Fax. 089 - 244333158 85577 Neubiberg mobil 0170 - 9317618

1 1

RE: Fun with GHC's optimiser
by Simon Peyton-Jones 02 Nov '00

02 Nov '00

I can never resist messages like these, even when I'm meant to be doing other things. It's very helpful when people offer fairly precise performance-bug reports. Thanks! | I am wondering whether there is a particular reason why the | optimiser doesn't pull the | | (1) a = NO_CCS PArray! [wild1 mba#]; This one is a definite bug. It turns out that the head of the before-ghci-branch doesn't have this bug, so I'm disinclined to investigate it further. | (2) case w of wild3 { | I# e# -> | | As for (2), the loop would be nice and straight if that | unboxing where outside of the loop - as it is, we break the | pipeline once per iteration it seems This one is a bit harder. Basically we want to make a wrapper for a recursive function if it's sure to evaluate its free variables. In fact the 'liberate-case' pass (which isn't switched on in 4.08) is meant to do just this. It's in simplCore/LiberateCase.lhs, and it's not very complicated. I've just tried it and it doesn't seem to have the desired effect, but I'm sure that's for a boring reason. If anyone would like to fix it, go ahead! (You can't just say '-fliberate-case' on the command line to make it go; you have to add -fliberate-case at a sensible point to the minusOflags in driver/Main.hs.) Incidentally, you'll find that -ddump-simpl gives you a dump that is pretty close to STG and usually much more readable. Most performance bugs show up there. -dverbose-simpl gives you more clues about what is happening where. | Also if somebody is looking at the attached source, I was | wondering why, when I use the commented out code in | `newPArray', I get a lot worse code (the STG code is in a | comment at the end of the file). In particular, the lambda | abstraction is not inlined, whereas `fill' gets inlined into | the code of which the dump is above. Is it because the | compiler has a lot harder time with explicit recursion than | with fold/build? If so, the right RULES magic should allow | me to do the same for my own recursively defined | combinators, shouldn't it? I couldn't figure out exactly what you meant. The only commented out code is STG code. Maybe send a module with the actual source you are bothered about. S

2 1

RE: Fun with GHC's optimiser
by Simon Marlow 02 Nov '00

02 Nov '00

> I am wondering whether there is a particular reason why the > optimiser doesn't pull the > > (1) a = NO_CCS PArray! [wild1 mba#]; > > and the > > (2) case w of wild3 { > I# e# -> I checked with the before-ghci-branch compiler, and it pulls out (1) but not (2). Simon did a fair amount of work on improving the compilation of IO-ish code and code with lots of newtypes in it after we noticed some problems like the ones you point out above. We'll need to investigate whether the case can be pulled out of the loop too, though. Cheers, Simon

1 0

RE: Quick question re RULES
by Simon Peyton-Jones 02 Nov '00

02 Nov '00

| PrelBase contains the appended code. Am I correct in | assuming that the stuff is structured as it is, because the | "map" rule first `breaks' the map `open', which exposes it | to the various foldr/build rules, and if no foldr/build rule | matches, the "mapList" rule `closes' it again in a later | phase of optimisation - after build was inlined? If so, it | seems like the whole thing depends a bit on the timing of | the various optimsations (the map might be closed again | before any of the foldr/build rules fires). Is this maybe | the reason that build has an INLINE 2 pragma, which delays | its inlining, and thus, the closing of the map? That's exactly it. | All very cunning, it seems ;-) A bit too cunning for comfort. I wish I could think of a better way to expose map's impl using build without paying a price for doing so if it turns out not to fuse with anything. But so far I've failed to do so. Is this a propos of your new transformations for parallelism? Simon

2 1