Re: Non-exhaustive pattern-match warning in code-example from Dependently Typed Programming with Singletons
Yes, this is a nuisance, esp because ghc can most of the time see perfectly well that if you *do* write down the missing cases that they are inaccessible. There are a bunch of open tickets about it. I too use Richard's trick; I tend to use foo _ _ = error inaccessible Fixing ghc so that it can always see that clauses are not actually missing might be difficult; perhaps the solution adopted in Agda would be easier, where you would write foo (SomeConstructor _) (SomeOtherConstructor _) () (where SomeConstructor and SomeOtherConstructor are the missing cases) to indicate that this is inaccessible pattern. -E On Mon, May 19, 2014 at 12:45 AM, Richard Eisenberg e...@cis.upenn.eduwrote: The short answer here (to Is there a way to avoid the non-exhaustive pattern-match warning?) is no, not in general. See #3927 ( https://ghc.haskell.org/trac/ghc/ticket/3927). ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Build failure of 7.8RC1 on OSX Mountain Lion
Possibly I did something wrong (certainly when I tried to build something very close to RC1 at Austin's request it worked fine), but now I am getting In file included from rts/sm/Evac.c:21:0: rts/sm/GCTDecl.h:71:0: error: thread-local storage not supported for this target (Host compiler: ghc 7.6.3, no mk/build.mk, standard ./configure --prefix=.., make) Any ideas? -Edsko ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Cannot build tagged with HEAD
I'm getting the errors below if I try to build tagged with head:
src/Data/Tagged.hs:57:5:
'Tagged' is applied to too many type arguments
In an expression type signature:
Tagged k s b - Tagged k s b - Bool
In the expression:
ghc-prim:GHC.Prim.coerce ((==) :: b - b - Bool) ::
Tagged k s b - Tagged k s b - Bool
In an equation for '==':
(==)
= ghc-prim:GHC.Prim.coerce ((==) :: b - b - Bool) ::
Tagged k s b - Tagged k s b - Bool
src/Data/Tagged.hs:57:9:
'Tagged' is applied to too many type arguments
In an expression type signature:
Tagged k s b - Tagged k s b - Ordering
In the expression:
ghc-prim:GHC.Prim.coerce (compare :: b - b - Ordering) ::
Tagged k s b - Tagged k s b - Ordering
In an equation for 'compare':
compare
= ghc-prim:GHC.Prim.coerce (compare :: b - b - Ordering) ::
Tagged k s b - Tagged k s b - Ordering
src/Data/Tagged.hs:57:14:
'Tagged' is applied to too many type arguments
In an expression type signature:
(,) (Tagged k s b) (Tagged k s b) - [] (Tagged k s b)
In the expression:
ghc-prim:GHC.Prim.coerce (range :: (,) b b - [] b) ::
(,) (Tagged k s b) (Tagged k s b) - [] (Tagged k s b)
In an equation for 'range':
range
= ghc-prim:GHC.Prim.coerce (range :: (,) b b - [] b) ::
(,) (Tagged k s b) (Tagged k s b) - [] (Tagged k s b)
src/Data/Tagged.hs:57:18:
'Tagged' is applied to too many type arguments
In an expression type signature: Tagged k s b
In the expression:
ghc-prim:GHC.Prim.coerce (minBound :: b) :: Tagged k s b
In an equation for 'minBound':
minBound = ghc-prim:GHC.Prim.coerce (minBound :: b) :: Tagged k s b
Line 57 is the ( in
newtype Tagged s b = Tagged { unTagged :: b } deriving
( Eq, Ord, Ix, Bounded
#if __GLASGOW_HASKELL__ = 707
, Typeable
#endif
)
Anyone any ideas what's going on?
-E
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Pattern match failure in StgCmmExpr.hs when adding new out-of-line primop
Hi guys, I'm trying to add a new primop; as a starting point I just copied the definition of catch# in primops.txt.pp and renamed catch# to catchRethrow#, and added the corresponding declarations following https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps#AddinganewPrimOp ; however, when I do this, I get ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20131108 for x86_64-apple-darwin): compiler/codeGen/StgCmmExpr.hs:508:15-48: Irrefutable pattern failed for pattern (CoreSyn.DEFAULT, deflt) I can't quite figure out why that is happening and how I should address it. Any suggestions? Thanks! -E ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern match failure in StgCmmExpr.hs when adding new out-of-line primop
Hi Arash, On Tue, Nov 12, 2013 at 10:44 AM, Arash Rouhani rar...@student.chalmers.se wrote: I'm really curious why you want a catchRethrow. I'm tempted to add such a primop myself since I'm working on problems with stack traces. I'm really interested in what use-case you had in mind. I'm working on dealing with problems with re-throwing asynchronous exceptions, especially in the context of using unsafePerformIO (see #8006 and the other tickets I reference there at the top). The catchRethrow I'm playing with is supposed to be used something like threadCode :: IO () threadCode = catch (print notReallyPure) outerHandler where outerHandler :: SomeException - IO () outerHandler e = logMsg $ Outer handler: ++ show e notReallyPure :: Integer notReallyPure = unsafePerformIO $ catchRethrow (go 10) innerHandler where go :: Integer - IO Integer go 0 = return 1234 go n = do logMsg (show n) threadDelay 10 go (n - 1) innerHandler :: SomeException - IO Integer - IO Integer innerHandler e rethrow = do logMsg $ Inner handler: ++ show e rethrow logMsg :: String - IO () logMsg str = do tid - myThreadId putStrLn $ show tid ++ : ++ str Given this main: main :: IO () main = do a1 - async threadCode a2 - async threadCode threadDelay 50 cancel a1 wait a2 return () It should be the case that when thread a1 gets interrupted, thread a2 can continue evaluating the notReallyPure thunk without getting either an exception and without redoing any work. In other words, the output of this main should look like ThreadId 2: 10 ThreadId 2: 9 ThreadId 2: 8 ThreadId 2: 7 ThreadId 2: 6 ThreadId 2: Inner handler: thread killed ThreadId 2: Outer handler: thread killed ThreadId 3: 5 ThreadId 3: 4 ThreadId 3: 3 ThreadId 3: 2 ThreadId 3: 1 1234 -E ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows build failures in FD.hs
Hi all, I'm still trying to get a Windows build (Win 7, tried both 32-bit and 64-bit, same result) -- using THREADS=1. When running 'sh validate', compilation eventually stops with inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0-package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/IO/FD.hs -o libraries/base/dist-install/build/GHC/IO/FD.o -dyno libraries/base/dist-install/build/GHC/IO/FD.dyn_o libraries\base\GHC\IO\FD.hs:281:23: Empty 'do' block libraries\base\GHC\IO\FD.hs:282:23: Empty 'do' block libraries\base\GHC\IO\FD.hs:283:26: Not in scope: `devptr' libraries\base\GHC\IO\FD.hs:283:33: Not in scope: `inoptr' libraries\base\GHC\IO\FD.hs:284:20: Not in scope: `devptr' libraries\base\GHC\IO\FD.hs:284:34: Not in scope: `inoptr' make[1]: *** [libraries/base/dist-install/build/GHC/IO/FD.o] Error 1 make: *** [all] Error 2 Since nobody else seems to be experiencing this, there must be something wrong with my setup? I've tried to follow http://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows best I could, but I'm not a Windows user so I might have got something wrong. Any suggestions welcome! Edsko ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
Hi all, So I managed to remove 3 out of 4 of the -boot files. The one that remains, ironically, is the DsMonad.hs-boot. DsMonad has a (transitive) dependency on Hooks in at least two ways: once through Finder, which imports Packages, which imports Hooks; but that's easily solved, because Finder can import PackageState instead. However, it is less obvious to me how to resolve the following import cycle - DsMonad imports tcIfaceGlobal from TcIface - TcIface imports (loadWiredInHomeIface, loadInterface, loadDecls, findAndReadIface) from LoadIface - LoadIFace imports Hooks (There might be still others, this is the most direct one at the moment.) (Just to be clear, Hooks imports DsMonad because it needs the DsM type for the dsForeignsHook.) I'm sure this cycle can be broken somehow, but I'm not familiar enough with this part of the compiler to see if there is a natural point to do it. As things stand, we have a DsMonad.hs-boot which just exports the DsGblEnv, DsLclEnv, and DsM types. I don't know if this is something we should be worrying about or not? Just to summarize: the hooks patch as things stand now introduces the Hooks enumeration, rather than a separate type per hook so that we have a central and type checked list of all hooks; in order to do that, it moves some things around (some times moves to HscTypes), introduces a new module called PipelineMonad as per SPJ's suggestion, and introduces a single additional boot file for the DsMonad module. Edsko On Tue, Sep 10, 2013 at 12:40 PM, Simon Peyton-Jones simo...@microsoft.com wrote: I do like the single record. I would really really like a strong clear Note [blah] on the hooks::Dynamic field of DynFlags. It’s *so* non-obvious why it’s dynamic, and the reason is a really bad one, namely the windows DLL split nonsense. (Not our fault but still needs very clear signposting.) I don’t understand why we need 4 new hs-boot files. Eg why DsMonad.hs-boot? It should be safely below Hooks. Linker.hs-boot is solely because of LibrarySpec. It would be possible to push that into HscTypes. (Again with a comment to explain why.) DriverPipeline is aleady 2,100 lines long, and could reasonably be split with CompPipeline in the PipelineMonad module, say. In other words, a bit of refactoring might eliminate the loops *and* sometimes arguably improve the code. I don’t feel terribly strongly about all this. It does feel a bit ad hoc… in a variety of places (eg deep in Linker.hs) there are calls to hooks, and it’s not clear to me why exactly those are the right places. But I suppose they are simply driven by what has been needed. Anyway if you two are happy (no one else seems to mind either way) then go ahead. Simon From: Luite Stegeman [mailto:stege...@gmail.com] Sent: 10 September 2013 08:37 To: Edsko de Vries Cc: Simon Peyton-Jones; ghc-devs; Edsko de Vries Subject: Re: GHC 7.8 release status Edsko has done some work of rearranging imports in DynFlags to make the DLL split work, and I've implemented the hooks on top of this, in a record, as discussed: - https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-record.patch (not final yet, but should be usable for testing) - demo program: https://gist.github.com/luite/6506064 Some disadvantages: - as long as the DLL split exists, more restructuring will be required if a new hook is added to something in a module on which DynFlags depends - 4 new hs-boot files required, new hooks will often require additional hs-boot files (when module A has a hook (so A imports Hooks, this can't be a source import), the hook will often have some types defined by A, so Hooks will have to import A) Advantages (over type families / Dynamic hooks): - Hooks neatly defined together in a single record I'm not so sure myself, but if everyone agrees that this is better than the older hooks I'll convert GHCJS to the new implementation later today and finalize the patch (comments are a bit out of date, and I'm not 100% sure yet that GHCJS doesn't need another hook for TH support in certain setups) and update the wiki. luite On Mon, Sep 9, 2013 at 4:55 PM, Edsko de Vries edskodevr...@gmail.com wrote: Simon, I talked to Luite this morning and I think we can come up with a design that includes the enumeration we prefer, with a single use of Dynamic in DynFlags -- it involves splitting off a PackageState module from Packages so that DynFlags doesn't depend on the entirely of Packages anymore (which would then, transitively, mean that it depends on Hooks and hence on a large part of ghc), but I think that should be doable. I'm working on that now. Edsko On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Edsko I’m very short of time right now. I think you understand the issues here. Can you do a round or two with Luite and emerge with a design that you both think is best
Re: Building GHC on Mac stops
Note that I opened a ticket about this (but with less information than
in this thread):
http://ghc.haskell.org/trac/ghc/ticket/8102
-E
On Tue, Aug 6, 2013 at 12:59 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
Hi Nicolas,
My guess is here: libraries/integer-gmp/configure generates gmp.h.
Building mkGmpDerivedConstants starts in parallel. Since configure
takes time, mkGmpDerivedConstants is build before gmp.h is
created.
How can we ensure that these two jobs are carried out sequentially?
--Kazu
I never determined how to fix this. Here's the notes I developed:
tl;dr For some reason, it seems gmp.h is not recognized as a dependency of
mkGmpDerivedConstants.o
HTH
-
If I run
$ perl boot; ./configure; make -j4
I tend to see a build failure. Immediately running make -j4 again succeeds.
In the following snippet from the log,
FILE=libraries/integer-gmp/mkGmpDerivedConstants/mkGmpDerivedConstants.c
{{{
/usr/bin/gcc -m64 -fno-stack-protector
-Ilibraries/integer-gmp/gmp
-Ilibraries/integer-gmp/mkGmpDerivedConstants/dist
-c FILE -o
libraries/integer-gmp/mkGmpDerivedConstants/dist/build/mkGmpDerivedConstants.o
FILE:15:17: error: gmp.h: No such file or directory
FILE: In function ‘main’:
FILE:68: error: ‘MP_INT’ undeclared (first use in this function)
FILE:68: error: (Each undeclared identifier is reported only once
FILE:68: error: for each function it appears in.)
FILE:69: error: expected expression before ‘)’ token
FILE:69: error: expected expression before ‘)’ token
FILE:70: error: expected expression before ‘)’ token
FILE:70: error: expected expression before ‘)’ token
FILE:71: error: expected expression before ‘)’ token
FILE:71: error: expected expression before ‘)’ token
make[1]: ***
[libraries/integer-gmp/mkGmpDerivedConstants/dist/build/mkGmpDerivedConstants.o]
Error 1
make[1]: *** Waiting for unfinished jobs
}}}
Some 1677 lines later, I see the line
cp libraries/integer-gmp/gmp/gmpbuild/gmp.h libraries/integer-gmp/gmp/
Which is I suppose why make -j4 succeeds the second time around.
I also see
libraries/integer-gmp/mkGmpDerivedConstants/ghc.mk:20:
libraries/integer-gmp/mkGmpDerivedConstants/dist/build/.depend.c_asm: No
such file or directory
many lines above.
On Mon, Aug 5, 2013 at 9:26 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
Hi,
I'm using GHC head (32bit) on Mac. Recently, building GHC head
stops:
% make maintainer-clean; perl boot; ./configure --prefix=/ghc-head; make
-j3
ranlib: file: .libs/libgmp.a(mp_clz_tab.o) has no symbols
ranlib: file: .libs/libgmp.a(obprintf.o) has no symbols
ranlib: file: .libs/libgmp.a(obvprintf.o) has no symbols
ranlib: file: .libs/libgmp.a(obprntffuns.o) has no symbols
ranlib: file: .libs/libgmp.a(repl-vsnprintf.o) has no symbols
libtool: link: rm -fr .libs/libgmp.lax
libtool: link: ( cd .libs rm -f libgmp.la cp -p ../libgmp.la
libgmp.la )
cp libraries/integer-gmp/gmp/gmpbuild/gmp.h libraries/integer-gmp/gmp/
cp libraries/integer-gmp/gmp/gmpbuild/.libs/libgmp.a
libraries/integer-gmp/gmp/
inplace/bin/mkdirhier libraries/integer-gmp/gmp/objs
cd libraries/integer-gmp/gmp/objs /usr/bin/ar x ../libgmp.a
ranlib libraries/integer-gmp/gmp/libgmp.a
ranlib: file: libraries/integer-gmp/gmp/libgmp.a(mp_clz_tab.o) has no
symbols
ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obprintf.o) has no symbols
ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obvprintf.o) has no
symbols
ranlib: file: libraries/integer-gmp/gmp/libgmp.a(obprntffuns.o) has no
symbols
ranlib: file: libraries/integer-gmp/gmp/libgmp.a(repl-vsnprintf.o) has no
symbols
make: *** [all] Error 2
%
One more make -j3 finishes the building. I'm sure that this does not
happen before.
Are there any guys who get this problem?
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can't make ghc on master
It might well be hsenv, which modifies your environment in a number of ways. I recommend using my approach to sandboxes, which works fine with ghc (http://www.edsko.net/2013/02/10/comprehensive-haskell-sandboxes/). -E On Mon, Aug 5, 2013 at 9:14 AM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: Hello guys, I'm trying a fresh compile from master. These are the steps I've taken: $ git clone http://darcs.haskell.org/ghc.git/ $ cd ghc $ ./sync-all --testsuite get followed by: cp mk/build.mk.sample mk/build.mk uncommenting #BuildFlavour = quick and finally: $ perl boot $ ./configure $ make But this is what I've got in the middle of make (just posting the relevant section): https://gist.github.com/adinapoli/6154219 As you can see I'm sandboxed inside hsenv, but I can't think of any reason this being the cause of the failure. Any ideas? Sorry for the naive question, A. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC head and .haddocks
Hi Ian, That says HADDOCK_DOCS=YES -E On Wed, Jul 24, 2013 at 11:31 PM, Ian Lynagh i...@well-typed.com wrote: Hi Edsko, On Tue, Jul 23, 2013 at 12:38:25PM +0200, Edsko de Vries wrote: I'm trying to build and install ghc head, with the installation of the .haddocks. I'm running into all kinds of trouble though. I have docbook and docbook-xsl installed, docbook isn't related to building haddock docs. am using the standard sample build.mk with the quick profile, modified to have HADDOCK_DOCS = YES BUILD_DOCBOOK_HTML = YES and configure confirms that it will build docs. A full 'make' however leaves the source tree without any .haddock files inside, What does make show VALUE=HADDOCK_DOCS say? Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Patch/feature proposal: Source plugins
Ok, I have now finally got managed to compile and test my code against ghc head. I have created a wiki page for the proposal http://ghc.haskell.org/trac/ghc/wiki/FrontendPluginsProposal and have attached patches against both 7.4.2 and against HEAD. Hopefully this is now a good starting point for a design that works for everybody. -E On Mon, Jul 8, 2013 at 10:46 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Edsko, Luite, Thomas, and others Thanks. I wonder whether you might write a Wiki page saying ·exactly what you want to achieve, with examples, and ·sketching how you hope to achieve it You may want to do a few rounds on that among yourselves; perhaps you have various different goals in mind that we can address at once. Selfishly, I don’t really want to review code until I have a very clear picture of what it is trying to achieve. (And I’m rushing towards the POPL deadline anyway!) Simon From: Edsko de Vries [mailto:edskodevr...@gmail.com] Sent: 08 July 2013 18:02 To: Simon Peyton-Jones Cc: Luite Stegeman; Thomas Schilling; ghc-devs@haskell.org; Nicolas Frisby Subject: Re: Patch/feature proposal: Source plugins Ok, sorry all for the delay. Attached is a frontend plugins patch for ghc 7.4.2. It will not work for ghc HEAD because the structure of the compiler has changed in various places, but I cannot currently compile my code against HEAD. Making this available now because it's been far too long already :) Comments/suggestions/feedback welcome. Hopefully the patch is pretty self-explanatory; and it's only small. -E On Mon, Jul 1, 2013 at 9:32 AM, Edsko de Vries edskodevr...@gmail.com wrote: Yes, I fully intend to create a ticket with a detailed description and a first patch, but I've been struggling with the latest HEAD, and specifically the fact that it now uses dynamic libraries for TH. I (think I am) stuck at a Cabal bug and I cannot currently build my code at all :-/ Duncan is looking into this though. Edsko On Fri, Jun 28, 2013 at 1:43 PM, Simon Peyton-Jones simo...@microsoft.com wrote: I’m confused as to details here. · Edsko is doing something; Nick is doing something else (attached for completeness). · I can’t locate a Trac Wiki page that describes the design I’m more than happy to adopt patches that improve the plugin API, but you’ll have to lead me through it! No hurry, just when you are ready. Simon From: Edsko de Vries [mailto:edskodevr...@gmail.com] Sent: 26 June 2013 09:21 To: Luite Stegeman Cc: Simon Peyton-Jones; Thomas Schilling; ghc-devs@haskell.org Subject: Re: Patch/feature proposal: Source plugins Hi Luite, I was fully planning on a first version of the patch yesterday, but so far my efforts were thwarted by annoying problems with dynamic libraries (not -- directly -- related to the patch at all). I will try again today :) Edsko On Wed, Jun 26, 2013 at 8:51 AM, Luite Stegeman stege...@gmail.com wrote: Any news on this? I'd really like to have this in GHC 7.8.1 so that we can release a fully working GHCJS with GhcMake functionality based on it. I'd be happy to help write the patch. luite On Tue, Jun 11, 2013 at 3:21 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Guys, I'm not following the details here, but I'm open to suggestions (patches, even) that improve the GHC API. Simon | -Original Message- | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] | On Behalf Of Thomas Schilling | Sent: 11 June 2013 12:53 | To: Edsko de Vries | Cc: ghc-devs@haskell.org | Subject: Re: Patch/feature proposal: Source plugins | | On 5 June 2013 13:51, Edsko de Vries edskodevr...@gmail.com wrote: | It is a little bit messy mostly because parts of the AST get lost | along the | way: quasi-quotes in the renamer, data type declarations and other | things | during type checking. A more ideal way, but also more time consuming, | would | be to change this so that the renamer leaves evidence of the quasi- | quotes in | the tree, and the type checker returns the entire tree type checked, | rather | than just a subset. I think that ultimately this is the better | approach, at | least for our purposes -- I'm not sure about other tools, but since | this | would be a larger change that affects larger parts of the ghc pipeline | I'm | not sure that I'll be able to do it. | | I needed something similar. In particular, I built a custom code | generator, but now I need a similar feature for extracting information | from a Haskell file (for IDE features). | | Since I needed to modify one-shot compilation mode I couldn't use the | GHC API. For the IDE stuff I'm using Shake as the build manager, so | that also needs a customized one-shot mode. For my current | implementation I just copied and adapted the necessary parts of | HscMain, DriverPipeline, etc
GHC head and .haddocks
Hi, I'm trying to build and install ghc head, with the installation of the .haddocks. I'm running into all kinds of trouble though. I have docbook and docbook-xsl installed, am using the standard sample build.mk with the quick profile, modified to have HADDOCK_DOCS = YES BUILD_DOCBOOK_HTML = YES and configure confirms that it will build docs. A full 'make' however leaves the source tree without any .haddock files inside, and a subsequent 'make install' does not install any .haddock files either. Moreover, curiously, no 'haddock' script is installed (only haddock-ghc-7.7.20130721) -- but perhaps that is expected? I can easily build the .haddock files manually by running make html stage=0 FAST=YES as per the wiki (inside, say, ../base/ in the source tree), and that works as expected, but a subsequent 'make install' in the root still does not install any .haddocks. I tried copying over the .haddock files manually, but now running haddock (copied from haddock-ghc-7.7.20130721) exits with haddock: internal error: /Users/dev/local/lib/ghc-7.7.20130721/html: getDirectoryContents: does not exist (No such file or directory) That path /Users/dev/local/lib/ghc-7.7.20130721 is specified as the topdir in the haddock script and passed to the actual executable with -B and -l , and indeed that's where the libraries are installed. However, I don't understand why it's looking in ~/local/lib/ghc-7.7.20130721/html, because the html documentation is not installed there (but in ~/local/share/doc/ghc/html/libraries/). I'm shooting in the dark here really, I'm not really sure what's going on or what I've done wrong. Any pointers would be appreciated! Thanks, Edsko ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC head and .haddocks
Ok, I just realized that that ~/local/lib/ghc-7.7.20130721/html directory it is looking for *does* exist in a normal build and contains themes and stuff. Copying that from inplace/lib/html in the ghc source tree avoids the internal error message, so this is probably just another manifestation of the failure to install the haddocks in the first place. I still don't know why that happened though (why it didn't build the .haddock files nor install them, or the inplace/lib/html directory). -E On Tue, Jul 23, 2013 at 12:38 PM, Edsko de Vries edskodevr...@gmail.com wrote: Hi, I'm trying to build and install ghc head, with the installation of the .haddocks. I'm running into all kinds of trouble though. I have docbook and docbook-xsl installed, am using the standard sample build.mk with the quick profile, modified to have HADDOCK_DOCS = YES BUILD_DOCBOOK_HTML = YES and configure confirms that it will build docs. A full 'make' however leaves the source tree without any .haddock files inside, and a subsequent 'make install' does not install any .haddock files either. Moreover, curiously, no 'haddock' script is installed (only haddock-ghc-7.7.20130721) -- but perhaps that is expected? I can easily build the .haddock files manually by running make html stage=0 FAST=YES as per the wiki (inside, say, ../base/ in the source tree), and that works as expected, but a subsequent 'make install' in the root still does not install any .haddocks. I tried copying over the .haddock files manually, but now running haddock (copied from haddock-ghc-7.7.20130721) exits with haddock: internal error: /Users/dev/local/lib/ghc-7.7.20130721/html: getDirectoryContents: does not exist (No such file or directory) That path /Users/dev/local/lib/ghc-7.7.20130721 is specified as the topdir in the haddock script and passed to the actual executable with -B and -l , and indeed that's where the libraries are installed. However, I don't understand why it's looking in ~/local/lib/ghc-7.7.20130721/html, because the html documentation is not installed there (but in ~/local/share/doc/ghc/html/libraries/). I'm shooting in the dark here really, I'm not really sure what's going on or what I've done wrong. Any pointers would be appreciated! Thanks, Edsko ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Patch/feature proposal: Source plugins
Ok, sorry all for the delay. Attached is a frontend plugins patch for ghc 7.4.2. It will not work for ghc HEAD because the structure of the compiler has changed in various places, but I cannot currently compile my code against HEAD. Making this available now because it's been far too long already :) Comments/suggestions/feedback welcome. Hopefully the patch is pretty self-explanatory; and it's only small. -E On Mon, Jul 1, 2013 at 9:32 AM, Edsko de Vries edskodevr...@gmail.comwrote: Yes, I fully intend to create a ticket with a detailed description and a first patch, but I've been struggling with the latest HEAD, and specifically the fact that it now uses dynamic libraries for TH. I (think I am) stuck at a Cabal bug and I cannot currently build my code at all :-/ Duncan is looking into this though. Edsko On Fri, Jun 28, 2013 at 1:43 PM, Simon Peyton-Jones simo...@microsoft.com wrote: I’m confused as to details here. **· **Edsko is doing something; Nick is doing something else (attached for completeness). **· **I can’t locate a Trac Wiki page that describes the design** ** ** ** I’m more than happy to adopt patches that improve the plugin API, but you’ll have to lead me through it! ** ** No hurry, just when you are ready. ** ** Simon ** ** *From:* Edsko de Vries [mailto:edskodevr...@gmail.com] *Sent:* 26 June 2013 09:21 *To:* Luite Stegeman *Cc:* Simon Peyton-Jones; Thomas Schilling; ghc-devs@haskell.org *Subject:* Re: Patch/feature proposal: Source plugins ** ** Hi Luite, ** ** I was fully planning on a first version of the patch yesterday, but so far my efforts were thwarted by annoying problems with dynamic libraries (not -- directly -- related to the patch at all). I will try again today :) ** ** Edsko ** ** On Wed, Jun 26, 2013 at 8:51 AM, Luite Stegeman stege...@gmail.com wrote: Any news on this? I'd really like to have this in GHC 7.8.1 so that we can release a fully working GHCJS with GhcMake functionality based on it. I'd be happy to help write the patch. ** ** luite ** ** ** ** On Tue, Jun 11, 2013 at 3:21 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Guys, I'm not following the details here, but I'm open to suggestions (patches, even) that improve the GHC API. Simon | -Original Message- | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org ] | On Behalf Of Thomas Schilling | Sent: 11 June 2013 12:53 | To: Edsko de Vries | Cc: ghc-devs@haskell.org | Subject: Re: Patch/feature proposal: Source plugins | | On 5 June 2013 13:51, Edsko de Vries edskodevr...@gmail.com wrote: | It is a little bit messy mostly because parts of the AST get lost | along the | way: quasi-quotes in the renamer, data type declarations and other | things | during type checking. A more ideal way, but also more time consuming, | would | be to change this so that the renamer leaves evidence of the quasi- | quotes in | the tree, and the type checker returns the entire tree type checked, | rather | than just a subset. I think that ultimately this is the better | approach, at | least for our purposes -- I'm not sure about other tools, but since | this | would be a larger change that affects larger parts of the ghc pipeline | I'm | not sure that I'll be able to do it. | | I needed something similar. In particular, I built a custom code | generator, but now I need a similar feature for extracting information | from a Haskell file (for IDE features). | | Since I needed to modify one-shot compilation mode I couldn't use the | GHC API. For the IDE stuff I'm using Shake as the build manager, so | that also needs a customized one-shot mode. For my current | implementation I just copied and adapted the necessary parts of | HscMain, DriverPipeline, etc. That's very messy, fragile and breaks | on every GHC release so I'd really like to see the necessary features | put into GHC. | | Do you have a working patch somewhere? | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ** ** ** ** ghc-7.4.2-frontend-plugins.diff Description: Binary data ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Patch/feature proposal: Source plugins
Hi Luite, I was fully planning on a first version of the patch yesterday, but so far my efforts were thwarted by annoying problems with dynamic libraries (not -- directly -- related to the patch at all). I will try again today :) Edsko On Wed, Jun 26, 2013 at 8:51 AM, Luite Stegeman stege...@gmail.com wrote: Any news on this? I'd really like to have this in GHC 7.8.1 so that we can release a fully working GHCJS with GhcMake functionality based on it. I'd be happy to help write the patch. luite On Tue, Jun 11, 2013 at 3:21 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Guys, I'm not following the details here, but I'm open to suggestions (patches, even) that improve the GHC API. Simon | -Original Message- | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org ] | On Behalf Of Thomas Schilling | Sent: 11 June 2013 12:53 | To: Edsko de Vries | Cc: ghc-devs@haskell.org | Subject: Re: Patch/feature proposal: Source plugins | | On 5 June 2013 13:51, Edsko de Vries edskodevr...@gmail.com wrote: | It is a little bit messy mostly because parts of the AST get lost | along the | way: quasi-quotes in the renamer, data type declarations and other | things | during type checking. A more ideal way, but also more time consuming, | would | be to change this so that the renamer leaves evidence of the quasi- | quotes in | the tree, and the type checker returns the entire tree type checked, | rather | than just a subset. I think that ultimately this is the better | approach, at | least for our purposes -- I'm not sure about other tools, but since | this | would be a larger change that affects larger parts of the ghc pipeline | I'm | not sure that I'll be able to do it. | | I needed something similar. In particular, I built a custom code | generator, but now I need a similar feature for extracting information | from a Haskell file (for IDE features). | | Since I needed to modify one-shot compilation mode I couldn't use the | GHC API. For the IDE stuff I'm using Shake as the build manager, so | that also needs a customized one-shot mode. For my current | implementation I just copied and adapted the necessary parts of | HscMain, DriverPipeline, etc. That's very messy, fragile and breaks | on every GHC release so I'd really like to see the necessary features | put into GHC. | | Do you have a working patch somewhere? | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Patch/feature proposal: Provide access to the runStmt sandbox ThreadID
Hi, I believe the right way to fix this is to find all the places in the compiler that catch and rethrow exceptions inside unsafePerformIO, and make them use throwTo when the exception is asynchronous. Ok, I have looked at this in detail and I'm not sure how feasible this is. I have filed a bug, with a test case, and a detailed explanation of my investigation so far: http://hackage.haskell.org/trac/ghc/ticket/8006. Edsko ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Patch/feature proposal: Source plugins
Hi all,
The plugin mechanism gives access to the program in Core; this suffices for
many but not quite all purposes. Tools that need access to the original AST
can call typecheckModule directly, but of course this requires using the
GHC API directly. Moreover, even when using the GHC API directly anyway (as
in my case), it means that tools cannot take advantage of ghc's
infrastructure for dependency tracking, recompiling only changed modules,
etc.
Hence it would be useful to have source plugins, which can be used both
externally and when using ghc API (in the latter case I guess hooks would
be the more appropriate terminology). Currently core plugins are recorded
as part of DynFlags as
pluginModNames:: [ModuleName],
pluginModNameOpts :: [(ModuleName,String)],
This makes sense when thinking of plugins only as an external mechanism,
but is less convenient when using them as internal hooks, too. In my draft
patch I introduce a new type HscPlugin (described shortly) and added
sourcePlugins :: [HscPlugin],
to DynFlags. HscPlugin is a record of a pair of functions; having the
actual record here rather than a module name means that these functions
can have a non-empty closure, which is obviously convenient when using this
as a hook rather than an external plugin.
In my current version HscPlugin looks like
data HscPlugin = HscPlugin {
runHscPlugin :: forall m. MonadIO m
= DynFlags
- TcGblEnv
- m TcGblEnv
, runHscQQ :: forall m. MonadIO m
= Env TcGblEnv TcLclEnv
- HsQuasiQuote Name
- m (HsQuasiQuote Name)
}
runHscPlugin is the main function; it gets passed the TcGblEnv (which
contains the type checked AST as its tcd_binds field).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Patch/feature proposal: Source plugins
Uh. I'm sorry, I don't know why that email got sent, I was still
writing it. Please ignore it for now, will send the full version later :)
On Wed, Jun 5, 2013 at 12:14 PM, Edsko de Vries edskodevr...@gmail.comwrote:
Hi all,
The plugin mechanism gives access to the program in Core; this suffices
for many but not quite all purposes. Tools that need access to the original
AST can call typecheckModule directly, but of course this requires using
the GHC API directly. Moreover, even when using the GHC API directly anyway
(as in my case), it means that tools cannot take advantage of ghc's
infrastructure for dependency tracking, recompiling only changed modules,
etc.
Hence it would be useful to have source plugins, which can be used both
externally and when using ghc API (in the latter case I guess hooks would
be the more appropriate terminology). Currently core plugins are recorded
as part of DynFlags as
pluginModNames:: [ModuleName],
pluginModNameOpts :: [(ModuleName,String)],
This makes sense when thinking of plugins only as an external mechanism,
but is less convenient when using them as internal hooks, too. In my draft
patch I introduce a new type HscPlugin (described shortly) and added
sourcePlugins :: [HscPlugin],
to DynFlags. HscPlugin is a record of a pair of functions; having the
actual record here rather than a module name means that these functions
can have a non-empty closure, which is obviously convenient when using this
as a hook rather than an external plugin.
In my current version HscPlugin looks like
data HscPlugin = HscPlugin {
runHscPlugin :: forall m. MonadIO m
= DynFlags
- TcGblEnv
- m TcGblEnv
, runHscQQ :: forall m. MonadIO m
= Env TcGblEnv TcLclEnv
- HsQuasiQuote Name
- m (HsQuasiQuote Name)
}
runHscPlugin is the main function; it gets passed the TcGblEnv (which
contains the type checked AST as its tcd_binds field).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Patch/feature proposal: Source plugins
Sorry for the earlier mishap, here's the full email.
Hi all,
The plugin mechanism gives access to the program in Core; this suffices for
many but not quite all purposes. Tools that need access to the original AST
can call typecheckModule directly, but of course this requires using the
GHC API directly. Moreover, even when using the GHC API directly anyway (as
in my case), it means that tools cannot take advantage of ghc's
infrastructure for dependency tracking, recompiling only changed modules,
etc.
Hence it would be useful to have source plugins, which can be used both
externally and when using ghc API (in the latter case I guess hooks would
be the more appropriate terminology). Currently core plugins are recorded
as part of DynFlags as
pluginModNames:: [ModuleName],
pluginModNameOpts :: [(ModuleName,String)],
This makes sense when thinking of plugins only as an external mechanism,
but is less convenient when using them as internal hooks, too. In my draft
patch I introduce a new type HscPlugin (described shortly) and added
sourcePlugins :: [HscPlugin],
to DynFlags. HscPlugin is a record of a pair of functions; having the
actual record here rather than a module name means that these functions
can have a non-empty closure, which is obviously convenient when using this
as a hook rather than an external plugin.
In my current version HscPlugin looks like
data HscPlugin = HscPlugin {
runHscPlugin :: forall m. MonadIO m
= DynFlags
- TcGblEnv
- m TcGblEnv
, runHscQQ :: forall m. MonadIO m
= Env TcGblEnv TcLclEnv
- HsQuasiQuote Name
- m (HsQuasiQuote Name)
}
runHscPlugin is the main function; it gets passed the TcGblEnv (which
contains the type checked AST as its tcd_binds field) and gets a change to
return it modified (we don't currently take advantage of that; I did that
only to be in line with core plugins).
Unfortunately, the typechecked AST is only a subset of the renamed AST (see
http://www.haskell.org/pipermail/ghc-devs/2013-February/000540.html). The
TcGblEnv contains a tcg_rn_decls field, which is a reference to the full
renamed (as opposed to typechecked) AST, but by default this is not
initialized: the typechecker only optionally retains the renamed AST, and
this is hardcoded to by False. In my current patch I have changed this so
that it's hard coded to be True; ideally this should become an option in
DynFlags (more ideal still would be if the type checked AST would not lose
any information).
Unfortunately, even the renamer loses information: quasi-quotes get
expanded during renaming and all evidence of that there was ever a
quasi-quote there has disappeared when the renamer returns. For this
reason, the HscPlugin type that I'm using at the moment also has a hook for
quasi-quotes.
So what I have currently done is:
1. Introduced the above HscPlugin type and added a corresponding field
to DynFlags
2. Call runHscQQ in the renamer whenever a quasi-quote gets expanded.
3. Make sure that the typechecker passes the result of the renamer
through.
4. Call runHscPlugin on the result of the typechecker.
In my client code I then combine the information obtained from these three
sources (2, 3, 4).
The path of least resistance for me currently to submit this as a patch for
ghc therefore be to submit a patch that does precisely what I described
above, mutatis mutandis based on your feedback, except that I would add an
option to add to DynFlags that would tell the type checker whether or not
to pass the result of the renamer through, rather than hardcoding it.
It is a little bit messy mostly because parts of the AST get lost along the
way: quasi-quotes in the renamer, data type declarations and other things
during type checking. A more ideal way, but also more time consuming, would
be to change this so that the renamer leaves evidence of the quasi-quotes
in the tree, and the type checker returns the entire tree type checked,
rather than just a subset. I think that ultimately this is the better
approach, at least for our purposes -- I'm not sure about other tools, but
since this would be a larger change that affects larger parts of the ghc
pipeline I'm not sure that I'll be able to do it.
Any and all feedback on the above would be appreciated!
Edsko
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Patch/feature proposal: Provide access to the runStmt sandbox ThreadID
Hi all, This proposal is related to http://hackage.haskell.org/trac/ghc/ticket/1381, which Simon Marlow closed through commit https://github.com/ghc/ghc/commit/02c4ab049adeb77b8ee0e3b98fbf0f3026eee453. The problem, in a nutshell, is how do we terminate a code snippet started with runStmt? Before Simon's patch the only way was to disable ghc's sandboxing, so that the snippet would run in the same thread as the thread that called runStmt in the first place, and then send an asynchronous exception to that thread. This is the approach we used to take. It's a little tricky to get right (have to make sure that these exceptions are thrown only at the right times), but we thought we had it working okay. Until, that is, we realized we had a very nasty problem: snippets were being unexpected interrupted. To debug this, we introduced a CustomUserInterruption data type to serve as the exception that we were throwing. This had two purposes: first, we would be use that if we saw a CustomUserInterrupt that it could only have come from one particular throw, and second, the CustomUserInterrupt carried an integer which was incremented on every throw so that we never threw the same exception twice. What we realized is that snippets were being interrupted by *old* exceptions; that is, exceptions that we had thrown to *previous* snippets (and had been caught too). This should obviously never happen. Ian managed to reproduce this behaviour in a completely different setting ( http://hackage.haskell.org/trac/ghc/ticket/5902#comment:5) and we think that something similar (unsafePerformIO related) must be happening inside ghc. Moreover, a further conjecture is that this only happens when runStmt is still compiling the snippet to be executed (as opposed to the snippet actually executing) -- i.e., that the exception gets stuck in the bowels of ghc somewhere. We don't have any hard evidence for this, other than the problem has not appeared again with the proposed patch (but that might be luck, as it depends on timing). The patch as we currently have it is against 7.4.2, so pre Simon's change for the sandbox behaviour -- but I don't think that Simon's changes affect the above problem. The core of our patch is -sandboxIO :: DynFlags - MVar Status - IO [HValue] - IO Status -sandboxIO dflags statusMVar thing = +sandboxIO :: DynFlags - MVar Status - MVar (Maybe ThreadId) - IO [HValue] - IO Status +sandboxIO dflags statusMVar tidMVar thing = mask $ \restore - -- fork starts blocked - let runIt = liftM Complete $ try (restore $ rethrow dflags thing) + let thing' = gbracket (myThreadId = putMVar tidMVar . Just) + (\() - modifyMVar_ tidMVar (\_ - return Nothing)) + (\() - thing) + runIt = liftM Complete $ try (restore $ rethrow dflags thing') in if dopt Opt_GhciSandbox dflags then do tid - forkIO $ do res - runIt putMVar statusMVar res -- empty: can't block That is, sandboxIO takes an additional MVar (Maybe ThreadId): 1. Initially this MVar should be empty. The MVar gets initialized to Just the Thread ID of the sandbox when the user code starts running. This means that if an secondary thread attempts to read the MVar (in order to kill the snippet), that secondary thread will block until the user code starts running -- it will not interrupt ghc when compiling the snippet. 2. When the user code exists the MVar is updated to be Nothing. This means that if the auxiliary thread reads the MVar and finds Nothing it knows that the snippet has already terminated. 3. When the auxiliary thread finds Just a thread ID (it must use withMVar rather than readMVar to avoid a race condition) it can safely throw the asynchronous exception. The remainder of the patch just propagates these changes up so that runStmt takes this MVar as an argument, too. Probably when integrating the patch into ghc it would be better to leave runStmt along and provide a runStmt' that takes the additional argument. Again, any and all feedback on the above would be appreciated. Edsko ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stability of Uniques
Hmm. Thank you for pointing this out, it made me realize things are more
subtle than I had thought. The uniques in the typechecked AST correspond to
the 'abe_mono' field of ABExport (the monomorphic bindings within a binding
group), while the uniques in the renamed AST correspond to the 'abe_poly'
fields instead (you can see this in your example too).
Edsko
PS. Reading that understanding the True Meaning of [ABExport] could get me
a PhD in the ghc comments was a little frightening :)
On Wed, Mar 27, 2013 at 2:37 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Indeed the type checker does not actually clone identifiers.
** **
ghc -c -ddump-rn -ddump-tc -dppr-debug Foo.hs
** **
Renamer
nonrec {Foo.hs:3:1-8}
main:Foo.f{v r0}
main:Foo.*f{v r0}*
= {Foo.hs:3:5-8}
ghc-prim:GHC.Types.True{(w) d 6u}
** **
TYPE SIGNATURES
( main:Foo.f{v r0} [lid] :: ghc-prim:GHC.Types.Bool{(w) tc 3c} ) ::
ghc-prim:GHC.Types.Bool{(w) tc 3c}
TYPE CONSTRUCTORS
COERCION AXIOMS
Dependent modules: []
Dependent packages: [base, ghc-prim, integer-gmp]
** **
Typechecker
{Foo.hs:3:1-8}
AbsBinds
[]
[]
[( main:Foo*.f{v r0}* [lid] :: ghc-prim:GHC.Types.Bool{(w) tc 3c} ) = (
f{v a9H} [lid] :: ghc-prim:GHC.Types.Bool{(w) tc 3c} )
]
( main:Foo.f{v r0} [lid] :: ghc-prim:GHC.Types.Bool{(w) tc 3c} )
:: ghc-prim:GHC.Types.Bool{(w) tc 3c}
[LclId]
{Foo.hs:3:1-8}
( f{v a9H} [lid] :: ghc-prim:GHC.Types.Bool{(w) tc 3c} )
:: ghc-prim:GHC.Types.Bool{(w) tc 3c}
[LclId]
( f{v a9H} [lid] :: ghc-prim:GHC.Types.Bool{(w) tc 3c} )
= {Foo.hs:3:5-8}
ghc-prim:GHC.Types.True{(w) v 6v}
EvBinds{}
** **
** **
** **
*From:* Edsko de Vries [mailto:edskodevr...@gmail.com]
*Sent:* 27 March 2013 14:04
*To:* Simon Peyton-Jones
*Cc:* ghc-devs@haskell.org
*Subject:* Re: Stability of Uniques
** **
So is there any way that I can see that an identifier in the renamed AST
is really the same as an identifier in the typechecked AST?
** **
On Wed, Mar 27, 2013 at 1:57 PM, Simon Peyton-Jones simo...@microsoft.com
wrote:
Yes, locally-bound uniques change all the time, to maintain scoping
hygiene. But top-level things from other modules have uniques that do not
change.
simon
*From:* ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
*On Behalf Of *Edsko de Vries
*Sent:* 26 March 2013 15:05
*To:* ghc-devs@haskell.org
*Subject:* Stability of Uniques
Hi all,
Consider the very simple test
module Test2 where
f = True
When walking the AST after renaming I see that f has unique 1912603236 and
True has unique 905969694. However, when walking the typechecked AST f
seems to have unique 1627390565 instead. Should I expect that the unique
associated with identifiers changes between renaming and typechecking? Or
is there something else that I'm missing?
Thanks!
Edsko
** **
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stability of Uniques
So is there any way that I can see that an identifier in the renamed AST is really the same as an identifier in the typechecked AST? On Wed, Mar 27, 2013 at 1:57 PM, Simon Peyton-Jones simo...@microsoft.comwrote: Yes, locally-bound uniques change all the time, to maintain scoping hygiene. But top-level things from other modules have uniques that do not change. ** ** simon ** ** *From:* ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Edsko de Vries *Sent:* 26 March 2013 15:05 *To:* ghc-devs@haskell.org *Subject:* Stability of Uniques ** ** Hi all, ** ** Consider the very simple test ** ** module Test2 where f = True ** ** When walking the AST after renaming I see that f has unique 1912603236 and True has unique 905969694. However, when walking the typechecked AST f seems to have unique 1627390565 instead. Should I expect that the unique associated with identifiers changes between renaming and typechecking? Or is there something else that I'm missing? Thanks! Edsko ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Stability of Uniques
Hi all, Consider the very simple test module Test2 where f = True When walking the AST after renaming I see that f has unique 1912603236 and True has unique 905969694. However, when walking the typechecked AST f seems to have unique 1627390565 instead. Should I expect that the unique associated with identifiers changes between renaming and typechecking? Or is there something else that I'm missing? Thanks! Edsko ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Top-level type signatures in TcGblEnv?
Ah, yes. But I am interested in the SrcSpan of the *usage site* (as well as the binding site). Edsko On Mon, Feb 25, 2013 at 4:41 PM, Simon Peyton-Jones simo...@microsoft.comwrote: The SrcSpan of the binding site is stored inside the Id. getSrcSpan should do it. ** ** S ** ** *From:* Edsko de Vries [mailto:edskodevr...@gmail.com] *Sent:* 25 February 2013 16:27 *To:* Simon Peyton-Jones *Cc:* ghc-devs@haskell.org *Subject:* Re: Top-level type signatures in TcGblEnv? ** ** I'm sorry, I don't see any location information (Located .. types) in tcg_type_env? ** ** Edsko ** ** On Mon, Feb 25, 2013 at 3:22 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Can’t you just use the range of the tcg_type_env? Simon *From:* Edsko de Vries [mailto:edskodevr...@gmail.com] *Sent:* 18 February 2013 14:03 *To:* Simon Peyton-Jones *Cc:* ghc-devs@haskell.org *Subject:* Top-level type signatures in TcGblEnv? Dear Simon, other ghc devs, I hooked into genericHscRecompile to traverse the typechecked source and construct an environment of type [(SrcSpan, Id)] recording all identifiers in the source with their type, definition site, etc. To be precise, I am traversing the tcg_binds :: LHsBinds Id, -- Value bindings in this module field of the TcGblEnv structure returned by the type checker. The problem is that I have so far been unable to find top-level user-supplied type annotations inside LHsBinds. The closest thing I've found is the PostTcType of a MatchGroup, but that is not Located; what I'm really looking for is an LSig. Now, let-bindings get a HsValBindsLR instead of an LHsBinds, and that *does* contain signatures. My question is two-fold: 1. First, am I missing something? Are there LSigs somewhere inside the TcGblEnv where I simply haven't seen them? 2. If not, is there a good reason why tcg_binds is an LHsBinds rather than an HsValBindsLR? And if there isn't, would you accept a patch making the change? Thanks, Edsko ** ** ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
