- ghc-devs - Haskell.org

How to load & parse an HI (interface) file?
by Saurabh Nanda 03 Dec '17

03 Dec '17

(GHC newbie alert -- is this the right mailing list for these kind of questions?) I"m writing some code to figure out all the instances of particular type-classes and after exploring a lot of options (hlint, haskell-src-exts, annotations, doctests, etc), I realized that the compiler had already figured it out and written it to disk for me! More digging led me to https://www.stackage.org/haddock/lts-9.0/ghc-8.0.2/LoadIface.html#v:loadSrc… after which I got stuck. How does one call this function? Specifically: * What is SDoc and how to construct a reasonable value for this argument? * IsBootInterface would mostly be False, right? * What does `Maybe FastString` represent and how does one construct it? * Finally how does one evaluate the resulting monadic action to get access to the underlying `ModIface`? -- Saurabh.

4 8

Re: GHC typecheck API
by Németh Boldizsár 01 Dec '17

01 Dec '17

Thank you for the suggestions! Setting the -fdefer-type-errors flag is indeed a good way to do it (with also adding Opt_DeferTypedHoles and Opt_DeferOutOfScopeVariables for other kind of errors). Boldizsár 2017.12.01. 4:12 keltezéssel, Christopher Done írta: > I suppose setting -fdefer-type-errors would also be handy in this > scenario! > > On Thu, 30 Nov 2017 at 15:37, Simon Peyton Jones via ghc-devs > <ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org>> wrote: > > This sounds like a good project! > > For the most part things look good: > > * Most type checker errors arise from *type constraints*. The type > checkder tries to solve these, but returns an elaborated syntax > tree (i.e. typechecked, and annotated with types) even if > constraint solving fails. > > * Some renamer errors are like this, notably out-of-scope > variables. (They just show up as another constraint.) > > However there is historical baggage. Back in the beginning, most > errors were treated by throwing an exception in the typechecker > monad; such exceptions can be caught, so that we can get more than > one error from the file, but no syntax tree is returned. Example > let f = <expression> in <body> > If there was an error in <expression> we'd throw an exception, > catch it at the 'let', give 'f' the type > f :: forall a. a > and continue to typecheck <body>. > > The trouble with the exception stuff is that you don't get an > elaborated syntax tree. > > So: I think you can get some of the way today, just by returning > the tree anyway even if there is an error to report. But it'd > take a bit more work to make more and more errors into things that > don't throw an exception. (Look for failTc, failRn in thd code.) > > I'm not very familiar with the GHC API for this part, but others > will be. I'm certain it can be improved, so rather than hacking > around what is there already, do propose and implement improvements. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org > <mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Németh > | Boldizsár > | Sent: 30 November 2017 05:42 > | To: ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > | Subject: GHC typecheck API > | > | Dear GHC developers, > | > | I'm developing a framework for development tools for Haskell. I > use the > | GHC API to parse and typecheck the source files. I recently > started to > | work on a quick-fix (automatic program correction) for Haskell > source > | code (correcting parenthesis problems, like 'putStrLn "xxx" ++ > show a' > | ==> 'putStrLn ("xxx" ++ show a)'). To do that I need to get the > typed > | syntax tree even if the program contains type or rename errors. > I could > | only do this by a nasty hack, adding a new TH module finalizer > | (tcg_th_modfinalizers) to extract the type checker's state before it > | fails. Is there a "correct" way to do this? I would not like this > | refactorings to be unusable if the GHC API changes. > | > | By the way, if you know of any similar attempt please let me know. > | > | Sincerely, > | Boldizsár Németh > | haskelltools.org <http://haskelltools.org> > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org <http://ell.org>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com > <http://40microsoft.com>%7C364b8db55e064415650d08d537b > | > 5323f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636476173738772433&sda > | ta=Kf5rZYwht8ZGBtGNNH6Q44wLIeefxzHn2UfDIdrNNMU%3D&reserved=0 > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

3 3

GHC typecheck API
by Németh Boldizsár 30 Nov '17

30 Nov '17

Dear GHC developers, I'm developing a framework for development tools for Haskell. I use the GHC API to parse and typecheck the source files. I recently started to work on a quick-fix (automatic program correction) for Haskell source code (correcting parenthesis problems, like 'putStrLn "xxx" ++ show a' ==> 'putStrLn ("xxx" ++ show a)'). To do that I need to get the typed syntax tree even if the program contains type or rename errors. I could only do this by a nasty hack, adding a new TH module finalizer (tcg_th_modfinalizers) to extract the type checker's state before it fails. Is there a "correct" way to do this? I would not like this refactorings to be unusable if the GHC API changes. By the way, if you know of any similar attempt please let me know. Sincerely, Boldizsár Németh haskelltools.org

2 1

`binary` serializing datatypes deriving Generic wrong on arm (32bit) with GHC HEAD
by Moritz Angermann 28 Nov '17

28 Nov '17

Hi! while trying to make sure cross compilation with Template Haskell works properly with 8.4, I ran into the following situation: When serializing data types, e.g. `Name OccName NameFlavour` in the transmission of Template Haskell Splice results from a 32bit arm device to the x86_64 host ghc. We expect to see: ``` .- 0 (first constructor) .- 1 .- 4 (fifth constructor) .- 4 .- 3 v v v v v \NUL \NUL\NUL\NUL\NUL\NUL\NUL\NUL\SOHf \EOT \NUL \NUL\NUL\NUL\NUL\NUL\NUL\NUL\EOTmain \NUL\NUL\NUL\NUL\NUL\NUL\NUL\ETXTmp '--' '----------------------------------' '---------------------------------' NameSpace PkgName ModName '-------------------------------' '--------------------------------------------------------------------------------' OccName NameG NameSpace PkgName ModName :: NameFlavour '-----------------------------------------------------------------------------------------------------------------------' Name OccName NameFlavour :: Name ``` However, the `NameSpace` on the 32bit arm ends up being 8 bytes. Even though the full `Namespace` data type can be fully serialized in a single byte. The `binary` package tries to compute the size it needs for a generic data type, using the following logic (from binary/src/Data/Binary/Generic.hs): ``` class SumSize f where sumSize :: Tagged f Word64 newtype Tagged (s :: * -> *) b = Tagged {unTagged :: b} instance (SumSize a, SumSize b) => SumSize (a :+: b) where sumSize = Tagged $ unTagged (sumSize :: Tagged a Word64) + unTagged (sumSize :: Tagged b Word64) instance SumSize (C1 c a) where sumSize = Tagged 1 ``` Thus for a simple sum type `data X = A | B` we should get a `sumSize` of 2. The arm32 device however ends up getting 2^33, because `sumSize :: Tagged a Word64` and `sumSize :: Tagged b Word64` each end up being 2^32. With some help from the nice folks in #ghc, I was able to conjure up the following condensed test case: ``` {-# LANGUAGE DeriveGeneric, KindSignatures, PolyKinds, CPP, ScopedTypeVariables, TypeOperators, TypeSynonymInstances, FlexibleInstances #-} {-# OPTIONS_GHC -O2 #-} import GHC.Generics import Data.Word import Debug.Trace data X = A | B deriving (Show, Generic) main :: IO () main = print (sumSize :: Tagged (Rep X)) -- like traceShowId, but allows us to prepend a message. t :: Show a => String -> a -> a #if TRACE t msg x = traceShow (msg ++ show x) x #else t _ = id #endif class SumSize f where sumSize :: Tagged f newtype Tagged (s :: * -> *) = Tagged {unTagged :: WORD} deriving Show instance (SumSize a, SumSize b) => SumSize (a :+: b) where sumSize = t "SumSize (a :+: b): " $ Tagged $ unTagged (t "a :+: b => sumSize :: Tagged a: " $ sumSize :: Tagged a) + unTagged (t "a :+: b => sumSize :: Tagged b: " $ sumSize :: Tagged b) instance SumSize (C1 c a) where sumSize = t "SumSize (C1 c a): " $ Tagged 1 instance SumSize a => SumSize (M1 D c a) where sumSize = t "SumSize (M1 D c a): " $ Tagged . unTagged $ (sumSize :: Tagged a) ``` compiling this with `-DWORD=Word32 -DTRACE=1` yields the correct result (=2), with `-DWORD=Word64 -DTRACE=0` as well. With `-DWORD=Word64 -DTRACE=2` the wrong result (=2^33) Optimization flags seem not to play any role when everything is in a single module (as the test case). As such I have attached the `-ddump-simple -dsuppress-all` files for the Word64 and Word32 with TRACE=1, as well as the diff between the Word32 and Word64 dump. The output with WORD=Word32, TRACE=1 is: ``` "SumSize (C1 c a): Tagged {unTagged = 1}" "a :+: b => sumSize :: Tagged a: Tagged {unTagged = 4294967296}" "a :+: b => sumSize :: Tagged b: Tagged {unTagged = 4294967296}" "SumSize (a :+: b): Tagged {unTagged = 8589934592}" "SumSize (M1 D c a): Tagged {unTagged = 8589934592}" Tagged {unTagged = 8589934592} ``` with WORD=Word64, TRACE=1 is: ``` "SumSize (C1 c a): Tagged {unTagged = 1}" "a :+: b => sumSize :: Tagged a: Tagged {unTagged = 1}" "a :+: b => sumSize :: Tagged b: Tagged {unTagged = 1}" "SumSize (a :+: b): Tagged {unTagged = 2}" "SumSize (M1 D c a): Tagged {unTagged = 2}" Tagged {unTagged = 2} ``` Any help with this would be greatly appreciated! Cheers, Moritz PS: I'm not absolutely sure, but this might also be related to https://ghc.haskell.org/trac/ghc/ticket/13513

1 1

True multi stage Haskell
by Tim Sheard 27 Nov '17

27 Nov '17

After many years of hoping someone else would do this, I would like to make GHC into a true multi-stage programming language. Here is how I thought I might approach this. 1) Use the GHC as a library module. 2) Use the LLVM backend. I have no experience with either of these tools. Lets start simple, How would I write functions like compile :: String -> IO PtrToLLVMCode -- where the string is a small Haskell program. llvmCompile :: PtrToLLVMCode -> IO PtrToMachineCode jumpTo:: PtrToMachineCode -> IO ans -- where ans is the "type" of the string. Any thoughts on how to get started? What papers to read, examples to look at? I'd love to move to some more disciplined input type, a sort of (mono) typed program representation (with similar complexity) to Template Haskell Exp type. where (Exp t) is a data structure representing a Haskell program of type t. All offers of advice accepted. I'm trying to get started soon, and good advice about what to avoid is especially welcome. If any one wanted to help with this, that would be great. Tim Sheard

6 5

Can strict ST break referential transparency?
by Yuras Shumovich 23 Nov '17

23 Nov '17

Hello, I was evaluating a possibility that linear types can break referential transparency [1], exactly like lazy ST [2]. But on the way I realized that even strict ST may suffer from the same issue. If ST computation is interrupted by e.g. async exception, runtime will "freeze" it at the point where it was interrupted [3]. So the question: is the "freezed" computation just a normal thunk? Note that the runtime doesn't guarantee that a thunk will be evaluated only once [4]. If the "freezed" thunk captures e.g. STRef, and will be evaluated twice, its effect could become observable from outside, just like in case of lazy ST. I tried to check the theory by stress testing RTS. Unfortunately I immediately discovered a runtime crash [5], which is probably not related to my question. Hope someone will be able to clarify things for me. Thanks, Yuras. [1] https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment -345553071 [2] https://ghc.haskell.org/trac/ghc/ticket/14497 [3] See section 8 there: https://www.microsoft.com/en-us/research/wp-co ntent/uploads/2016/07/asynch-exns.pdf [4] https://www.microsoft.com/en-us/research/wp-content/uploads/2005/09 /2005-haskell.pdf [5] https://ghc.haskell.org/trac/ghc/ticket/14497

3 4

Re: [GHC] #14490: TTG Snags
by Alan & Kim Zimmerman 23 Nov '17

23 Nov '17

Yes, but it is not feasible before GHC 8.6, due to needing GHC >= 8.2 for bootstrapping. On 22 November 2017 at 15:26, GHC <ghc-devs(a)haskell.org> wrote: > #14490: TTG Snags > -------------------------------------+---------------------- > --------------- > Reporter: alanz | Owner: (none) > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 8.3 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: #14482 | Differential Rev(s): > Wiki Page: | > ImplementingTreesThatGrow | > -------------------------------------+---------------------- > --------------- > > Comment (by Shayan-Najd): > > > So making a Data instance per concrete version may be the best way to > go. Plan B. > > Regardless of the GHC version we use, the question is whether Plan B > really fixes the build-time problem. Can we test it? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14490#comment:31> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

2 1

Unstuck old messages
by John Wiegley 23 Nov '17

23 Nov '17

Hello everyone, I was doing some maintenance on the mailman server that hosts this list, and several messages that were stuck in the queue for what appears to be a rather long time have been released. The queue is now empty, so if these messages are no longer relevant, please ignore them. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

1 0

Re: Can strict ST break referential transparency?
by Yuras Shumovich 23 Nov '17

23 Nov '17

22-11-2017, Срд а 15:37 -0500, David Feuer напісаў: > If there is indeed a problem, I suspect the right way to fix it is to > make sure that no partially evaluated thunk is ever resumed twice. > Inter-thread exceptions are presumably rare enough that we don't have > to worry *too* much about their cost. Sounds reasonable. But probably it already works that way? Though it doesn't seem to be covered in the papers, and looks like nobody knows an answer to my question. It makes me worry a bit. On the other hand, right now resuming frozen thunk usually crashes/hangs as discovered in #14497. Nobody noticed that so far in the wild, so probably the subject is just a dark corner case, not worse the efforts. > > > David FeuerWell-Typed, LLP > -------- Original message --------From: Yuras Shumovich <shumovichy@g > mail.com> Date: 11/21/17 12:43 PM (GMT-05:00) To: ghc-devs <ghc-dev > s(a)haskell.org> Subject: Can strict ST break referential > transparency? > > Hello, > > I was evaluating a possibility that linear types can break > referential > transparency [1], exactly like lazy ST [2]. > > But on the way I realized that even strict ST may suffer from the > same > issue. If ST computation is interrupted by e.g. async exception, > runtime will "freeze" it at the point where it was interrupted [3]. > > So the question: is the "freezed" computation just a normal thunk? > Note > that the runtime doesn't guarantee that a thunk will be evaluated > only > once [4]. If the "freezed" thunk captures e.g. STRef, and will be > evaluated twice, its effect could become observable from outside, > just > like in case of lazy ST. > > I tried to check the theory by stress testing RTS. Unfortunately I > immediately discovered a runtime crash [5], which is probably not > related to my question. > > Hope someone will be able to clarify things for me. > > Thanks, > Yuras. > > [1] https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomme > nt > -345553071 > [2] https://ghc.haskell.org/trac/ghc/ticket/14497 > [3] See section 8 there: https://www.microsoft.com/en-us/research/wp- > co > ntent/uploads/2016/07/asynch-exns.pdf > [4] https://www.microsoft.com/en-us/research/wp-content/uploads/2005/ > 09 > /2005-haskell.pdf > [5] https://ghc.haskell.org/trac/ghc/ticket/14497 > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Re: Can strict ST break referential transparency?
by David Feuer 22 Nov '17

22 Nov '17

If there is indeed a problem, I suspect the right way to fix it is to make sure that no partially evaluated thunk is ever resumed twice. Inter-thread exceptions are presumably rare enough that we don't have to worry *too* much about their cost. David FeuerWell-Typed, LLP -------- Original message --------From: Yuras Shumovich <shumovichy(a)gmail.com> Date: 11/21/17 12:43 PM (GMT-05:00) To: ghc-devs <ghc-devs(a)haskell.org> Subject: Can strict ST break referential transparency? Hello, I was evaluating a possibility that linear types can break referential transparency [1], exactly like lazy ST [2]. But on the way I realized that even strict ST may suffer from the same issue. If ST computation is interrupted by e.g. async exception, runtime will "freeze" it at the point where it was interrupted [3]. So the question: is the "freezed" computation just a normal thunk? Note that the runtime doesn't guarantee that a thunk will be evaluated only once [4]. If the "freezed" thunk captures e.g. STRef, and will be evaluated twice, its effect could become observable from outside, just like in case of lazy ST. I tried to check the theory by stress testing RTS. Unfortunately I immediately discovered a runtime crash [5], which is probably not related to my question. Hope someone will be able to clarify things for me. Thanks, Yuras. [1] https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment -345553071 [2] https://ghc.haskell.org/trac/ghc/ticket/14497 [3] See section 8 there: https://www.microsoft.com/en-us/research/wp-co ntent/uploads/2016/07/asynch-exns.pdf [4] https://www.microsoft.com/en-us/research/wp-content/uploads/2005/09 /2005-haskell.pdf [5] https://ghc.haskell.org/trac/ghc/ticket/14497 _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0