- ghc-devs - Haskell.org

LclId -> GblId question
by Gabor Greif 30 May '18

30 May '18

Hi devs, I have a simple question, but could not find an answer yet. The same variable (I checked!) appears in two dumps with different names and different external visibilities. Which pass transforms this variable to a global id, and why? Shouldn't a LclId remain local along the entire optimisation chain? Any hint appreciated! Cheers and thanks, Gabor Snippets from dumps below ############################################################## -rw-r--r-- 1 ggreif sw12 3281225 May 29 14:14 TcSMonad.dump-stranal -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} lvl_sOra :: TcTyVarDetails [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] lvl_sOra = ghc-prim-0.5.3:GHC.Magic.noinline @ TcTyVarDetails vanillaSkolemTv ############################################################## -rw-r--r-- 1 ggreif sw12 1438015 May 29 14:14 TcSMonad.dump-simpl -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} TcSMonad.isFilledMetaTyVar_maybe2 :: TcTyVarDetails [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] TcSMonad.isFilledMetaTyVar_maybe2 = ghc-prim-0.5.3:GHC.Magic.noinline @ TcTyVarDetails vanillaSkolemTv ##############################################################

1 1

ghci recompilation avoidance
by Evan Laforge 30 May '18

30 May '18

After switching to git, I discovered that ghci is interpreting a lot of modules when it should have loaded the .o files (i.e. I get 'SomeModule (interpreted)' instead of 'Skipped SomeModule'). It turns out that git checkouts update the modtime on checked-out files, even when they get reverted back to their original contents. Shake has an option ChangeModtimeAndDigestInput to check file contents in addition to modtime to not get fooled by this, but ghc is still doing a plain modtime check. So shake correctly skips the rebuild on those modules, but ghci recompiles them anyway. This means I'm better off just disabling shake's digest check, since otherwise I can just never recompile that stuff at all. Would it be reasonable to do the same kind of check as shake in ghc? Namely, shake does a quick check if modtime has changed, but even if it has, it checks the file contents digest to make sure. My understanding is that ghc does the quick modtime check, and then does an expensive interface check. This would augment that to become a quick modtime check, then a quick-ish digest check, and then the expensive interface check. I guess the old input file digest will have to be stored somewhere, presumably in the .hi file, so it's not a totally trivial change. The benefit should be that anyone working with git should be able to reuse more .o files after branch checkouts. The two relevant places seem to be GHC.loadModule and DriverPipeline.runPhase. I'm willing to have a go at this if people think it's a good idea and I can get some pointers on the .hi plumbing if I get hung up there.

2 2

-ddump-simpl-phases
by Gabor Greif 29 May '18

29 May '18

Hi all, the manual mentions `-ddump-simpl-phases` but there is no such flag [1]. How should we fix this? Cheers, Gabor [1] $ git grep ddump-simpl-phases docs/users_guide/debugging.rst: outputs even more information than ``-ddump-simpl-phases``.

2 1

[ANNOUNCE] GHC 8.4.3 released
by Ben Gamari 29 May '18

29 May '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.3. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.3 This release includes a few bug fixes including: * A code generation bug resulting in crashing of some programs using UnboxedSums has been fixed (#15038). * #14381, where Cabal and GHC would disagree about abi-depends, resulting in build failures, has been worked around. Note that the work-around patch has already been shipped by several distributions in previous releases, so this change may not be visible to you. * By popular demand, GHC now logs a message when it reads a package environment file, hopefully eliminating some of the confusion wrought by this feature. * GHC now emits assembler agreeable to newer versions of Gnu binutils, fixing #15068. * SmallArray#s can now be compacted into a compact region Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/TeamGHC Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug

1 0

RE: An idea for a different style of metaprogramming evaluation using the optimiser
by Simon Peyton Jones 25 May '18

25 May '18

(Clearing up my inbox.) Sorry to be slow on this Matthew. A difficulty I see is that the optimiser must exhaustively evaluate until it gets to a quote. And that is not easy if you had $$$(if (reverse [1,2,3] == [3,2,1]) then .. else .. ) you'd probably get stuck. Or at least you'd have to be able to inline reverse, and (==) and all the typeclass machinery for dealing with (==). A merit of the current setup is that evaluation in a splice can call arbitrary libraries, including compiled ones (not just bytecode!). Also the current setup lets you inspect the environment a bit with the Q monad. We already have typed and untyped TH; as yet I'm not convinced that the advantages of a third route would pay for the costs. But don't let me discourage you. I love being convinced! (Bandwidth to think about this is limited though, hence delay.) Simon | -----Original Message----- | From: Matthew Pickering <matthewtpickering(a)gmail.com> | Sent: 27 February 2018 11:18 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: An idea for a different style of metaprogramming | evaluation using the optimiser | | Sorry I wasn't clear. I'll try to flesh out the power example in much | more detail. The general idea is that instead of using the bytecode | interpreter in order to evaluate splices, the optimiser is often | sufficient. | | The benefits of this are: | | 1. Cross platform. | 2. Simpler to use as you are not manually creating ASTs | 3. More predictable as there are never any IO actions. | | The motivation is to precisely tell the inliner what to do rather than | trying to convince it to do what you like as it is quite | unpredictable. | | | Take the staged power example. | | ``` | power :: Int -> R Int -> R Int | power n k = if n == 0 | then .< 1 >. | else .< ~k * ~(power (n-1) k) >. | ``` | | I propose introducing two new pieces of syntax $$$(..) and [||| ... | |||] which are pronounced splice and quote. We also introduce a new | type constructor R, for representation. We can informally give the | types | of quote and splice as a -> R a and R a -> a respectively. | | What are the limitations of $$$() and [||| |||]? The only way to make | `R` fragments is by quoting. It is also not allowed to inspect the | quoted code. The only way to interact with it is by splicing. | | Which would then mean we staged power like so. | | | ``` | power :: Int -> R Int -> R Int | power n k = if n == 0 | then [||| 1 |||]. | else [||| $$$(k) * $$$(power k (n-1)) |||] | ``` | | Then to use power, we might call it like.. | | ``` | $$$(power 3 [||| x |||]) | ``` | | which we hope evaluates to x * x * x * 1. | | The difference I am proposing is that instead of the bytecode | interpreter evaluating the splice, it is the optimiser which does the | evaluation. | | Concretely, we interpret a splice meaning "evaluate as much as | possible" and a quote as meaning "don't evaluate me any more". | By evaluate as much as possible, this means to be very keen to inline | functions including recursive ones. This sounds bad but it is the user | who is in control by | where they put the annotations. | | So in this example, we would evaluate as follows.. E marks an | "evaluation context" where we are very keen to evaluate. | | ``` | $$$(power 1 [||| x |||]) | => | E: power 1 [||| x |||] | => | E: if 1 == 0 then [||| 1 |||] else ... | => (Eval condition) | E: [||| $$$([||| x |||]) * $$$(power (1-0)) k |||] | => (Quote removes evaluation context) | $$$([||| x |||]) * $$$(power (1-0) k) | => (Eval $$$(k)) | x * $$$(power (1-0) k) | => (Eval $$$(power (1-0) k) | k * E: power (1 - 0) k | => (Unroll as we are in E) | k * E: if 0 == 0 then [||| 1 |||] ... | => | k* E: [||| 1 |||] | => | k * 1 | ``` | | So we can completely evaluate the splices properly in the evaluator if | the definitions are simple enough. | In this example, that isn't actually going to be the case as the | optimiser doesn't evaluate `3 == 0` for integers because it is | implemented using a primitive. | | If we rewrite the example using an inductive data type for the | recursive argument then we can see that it would work correctly. | | ``` | data Nat = Z | S Nat | | power :: Nat -> R Int -> R Int | power n k = case n of | Z -> [||| 1 |||] | (S n) -> [||| $$$(k) * $$$(power n k) |||] | ``` | | Then it is perhaps clearer that the optimiser is all we need in order | to evaluate $$$(power (S Z) [||| x |||]). The current implementation | of $$ and [||] would invoke the bytecode interpreter to do this | evaluation but it is unnecessary for this simple example which the | optimiser could do just as well. | | ``` | $$$(power (S Z) [|| x ||]) | => | E: power (S Z) [|| x ||] | => | E: case (S Z) of | Z -> [||| 1 |||] | (S n) -> [||| $$$([||| x |||]) * $$$(power n [||| x |||]) |||] | => (Case of known constructor) | E: [||| $$$([|| x ||]) * $$$(power Z [||| x |||) |||] | => Quote | $$$([||| x |||]) * $$$(power Z [||| x |||]) | => | k * $$$(power Z [||| x |||]) | => Splice | k * E: power Z [||| x |||] | => Inline power as we in E | k * E (case Z of Z -> [||| 1 |||]; S n ... ->) | => Case of known constructor | k * E: [||| 1 |||] | => | k * 1 | ``` | | | Hope that clears some things up. | | | Matt | | On Tue, Feb 27, 2018 at 10:37 AM, Simon Peyton Jones | <simonpj(a)microsoft.com> wrote: | > Matthew, I'm afraid I don't understand the proposal at all. Can you | give a few examples? | > | > S | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Matthew Pickering | > | Sent: 27 February 2018 09:59 | > | To: GHC developers <ghc-devs(a)haskell.org> | > | Subject: An idea for a different style of metaprogramming | evaluation | > | using the optimiser | > | | > | I've had an idea for a while of a different way we could evaluate | TH- | > | like splices which would be more lightweight and easier to work | with. | > | | > | The idea is to create a third quotation/splicing mechanism which | has | > | no introspection (like MetaML) but then to evaluate these quotes | and | > | splices in the optimiser rather than using the bytecode | interpreter. | > | | > | I am motivated by the many examples of recursive functions in | > | libraries, which when given a statically known argument should be | able | > | to be unrolled to produce much better code. It is understandable | that | > | the compiler doesn't try to do this itself but there should be an | easy | > | way for the user to direct the compiler to do so. (See also | > | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.r | > | | eddit.com%2Fr%2Fhaskell%2Fcomments%2F7yvb43%2Fghc_compiletime_evaluati | > | | on%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C9979850e7fb142a7e11c08d | > | | 57dc8dcb8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636553224038023 | > | | 725%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi | > | I6Ik1haWwifQ%3D%3D%7C- | > | | 1&sdata=%2FOQOcFIXduGY9wtWWEkbqd3qQ1715oCdaim0pCeSgrI%3D&reserved=0) | > | | > | An example to be concrete: | > | | > | Take the power function such that power k n computes k^n. | > | | > | power :: Int -> Int -> Int | > | power k n = if n == 0 | > | then 1 | > | else k * power k (n - 1) | > | | > | If we statically know n then we can create a staged version. We | use R | > | to indicate that an argument is dynamically known. | > | | > | power :: R Int -> Int -> R Int | > | power k n = if n == 0 | > | then .< 1 >. | > | else .< ~k * ~(power k (n-1)) >. | > | | > | One way to implement this in Haskell is to use typed template | haskell | > | quoting and splicing. | > | The key thing to notice about why this works is that in order to | > | splice `power k (n-1)` we need to evaluate `power k (n-1)` so | that we | > | have something of type `R Int` which we can then splice back into | the | > | quote. | > | | > | The way this is currently implemented is that the bytecode | interpreter | > | runs these splices in order to find out what they evaluate to. | > | | > | The idea is that instead, we add another mode which runs splices | in | > | the core-to-core optimiser. The optimiser performs evaluation by | beta | > | reduction, inlining and constant folding. For simple definitions | on | > | algebraic data types it does a very good job of eliminating | overhead. | > | As long as the call is not recursive. If we can just get the | optimiser | > | to inline recursive calls in a controlled manner as well, it | should do | > | a good job on the unrolled definition. | > | | > | The benefits of this are that it works across all platforms and | fits | > | nicely already into the compilation pipeline. It also fits in | nicely | > | with the intuition that a "quote" means to stop evaluating and a | > | "splice" means to evaluate. | > | | > | A disadvantage is that the optimiser is only a *partial* | evaluator | > | rather than an evaluator. It gets stuck evaluating things | containing | > | primitives and so on. I don't forsee this as a major issue but a | > | limitation that library authors should be aware of when writing | their | > | staged programs. To go back to the power example, the recursive | > | condition would have to be an inductively defined natural (data N | = Z | > | | S N) rather than an Int as the comparison operator for integers | > | can't be evaluated by the optimiser. It is already rather easy to | > | write staged programs which loop if you don't carefully consider | the | > | staging so this seems now worse than the status quo. | > | | > | Does this sound at all sensible to anyone else? | > | | > | Matt | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | > | | devs&data=04%7C01%7Csimonpj%40microsoft.com%7C9979850e7fb142a7e11c08d5 | > | | 7dc8dcb8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365532240380237 | > | | 25%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI | > | 6Ik1haWwifQ%3D%3D%7C- | > | | 1&sdata=CJgS3uH4hHw5Zups1fAiUtOnTzn%2ByCh1bg1auiMBcYM%3D&reserved=0

1 0

Inconsistency in CoreSubst invariant
by Joachim Breitner 25 May '18

25 May '18

Hi, Stephanie stumbled on this apparent inconsistency in CoreSubst, about what ought to be in the in_scope_set of a Subst. On the one hand, the file specifies #in_scope_invariant# The in-scope set contains at least those 'Id's and 'TyVar's that will be in scope /after/ applying the substitution to a term. 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. Note that the first sentence does not actually imply the second (unless you replace “Precisely” with “In particular”). But the comment even explicitly states: Make it empty, if you know that all the free vars of the substitution are fresh, and hence can't possibly clash Looking at the code I see that lookupIdSubst indeed expects all variables in either the actual substitution or in the in_scope_set: lookupIdSubst :: SDoc -> Subst -> Id -> CoreExpr lookupIdSubst doc (Subst in_scope ids _ _) v | not (isLocalId v) = Var v | Just e <- lookupVarEnv ids v = e | Just v' <- lookupInScope in_scope v = Var v' -- Vital! See Note [Extending the Subst] | otherwise = WARN( True, text "CoreSubst.lookupIdSubst" <+> doc <+> ppr v $$ ppr in_scope) Var v Note the warning! It seems that one of these three are true: A The invariant should be the first sentence; in particular; the in_scope_set contains all the free variables that are not substituted. The rest of that comment needs to be updated to reflect that. B The invariant should be the second sentence, and the WARN is bogus, i.e. WARNs about situations that are actually ok. The rest of that comment needs to be updated, and the WARN removed. C The invariant should be the second sentence, and the WARN is still ok there because, well, it is only a warning and only appears in DEBUG builds. The rest of that comment needs to be updated, the WARN remains. Which one is it? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 3

8.6.1 status
by Ben Gamari 23 May '18

23 May '18

Hi everyone, As noted a few weeks ago, the 8.6.1 fork is quickly approaching. Currently the plan is to cut the branch on Friday, 1 May 2018. After the branch there will likely be a few days of bug fixing and clean-up, followed by the alpha 1 release. Let me know if you have a patch which you would like to see included that hasn't yet been submitted for review. Cheers, - Ben

4 5

Quantified constraints
by Simon Peyton Jones 23 May '18

23 May '18

Friends Now that the Quantified Constraints proposal<https://github.com/Gertjan423/ghc-proposals/blob/quantified-constraints/pro…> is accepted, I want to commit it to GHC before the 8.6 release. It's up on https://phabricator.haskell.org/D4724 for your review. It's rebased on master, and validates clean. There's also a useful wiki page<https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints>. Thanks! Simon

1 0

Build Failure
by Ningning Xie 23 May '18

23 May '18

Hi everyone, I pulled from the head this morning and would like to rebase my local changes on it. Even before I do rebase, I got a build error. Everything is fine last time I built (almost one week ago). Then I tried to glone a new repo and the build gives me the same error message. After a little bit searching, the error message seems to be specific to MacOS (mine is Sierra 10.12.6). Platform info (Let me know if you need more information): *--- repo/ghc * *»* which ghc ghc: aliased to stack ghc *--- repo/ghc * *»* stack exec -- ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 *--- repo/ghc * *»* gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Has anyone encountered the same problem and any clue on how to solve it? Thanks, Ningning "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -H32m -O -Wall -this-unit-id integer-gmp-1.0.2.0 -hide-all-packages -i -ilibraries/integer-gmp/src/ -ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist-install/build/./autogen -Ilibraries/integer-gmp/dist-install/build/./autogen -Ilibraries/integer-gmp/include -Ilibraries/integer-gmp/dist-install/build/include -optP-include -optPlibraries/integer-gmp/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.3 -this-unit-id integer-gmp -Wall -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/integer-gmp/dist-install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/integer-gmp/dist-install/build -c libraries/integer-gmp/src//GHC/Integer/Logarithms.hs -o libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms.p_o -dyno libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms.dyn_o */var/folders/zq/tn9b58wn37b0yby0vm8_7_cr0000gn/T/ghc47691_0/ghc_3.s:221:8: **error:* * error: unsupported relocation with subtraction expression, symbol '_integerzmgmp_GHCziIntegerziType_quotInteger_closure' can not be undefined in a subtraction expression* * .long _integerzmgmp_GHCziIntegerziType_quotInteger_closure-(_sMi_info)+0* * ^* * |* *221 |* .long _integerzmgmp_GHCziIntegerziType_quotInteger_closure-(_sMi_info)+0 * |** ^* */var/folders/zq/tn9b58wn37b0yby0vm8_7_cr0000gn/T/ghc47691_0/ghc_3.s:318:8: **error:* * error: unsupported relocation with subtraction expression, symbol '_integerzmgmp_GHCziIntegerziType_quotInteger_closure' can not be undefined in a subtraction expression* * .long _integerzmgmp_GHCziIntegerziType_quotInteger_closure-(_cPd_info)+0* * ^* * |* *318 |* .long _integerzmgmp_GHCziIntegerziType_quotInteger_closure-(_cPd_info)+0 * |** ^* */var/folders/zq/tn9b58wn37b0yby0vm8_7_cr0000gn/T/ghc47691_0/ghc_3.s:390:8: **error:* * error: unsupported relocation with subtraction expression, symbol '_integerzmgmp_GHCziIntegerziType_quotInteger_closure' can not be undefined in a subtraction expression* * .long _integerzmgmp_GHCziIntegerziType_quotInteger_closure-(_cP8_info)+0* * ^* * |* *390 |* .long _integerzmgmp_GHCziIntegerziType_quotInteger_closure-(_cP8_info)+0 * |** ^* `gcc' failed in phase `Assembler'. (Exit code: 1) make[1]: *** [libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms.p_o] Error 1

2 1

Cannot compute type fingerprint in plugin, kinds/types are mixed
by alice 23 May '18

23 May '18

Hello again. I’m trying to make a function in a type-checking plugin that takes TyCoRep#Type and makes its fingerprint that matches `typeRepFingerprint (typeRep :: TypeRep (type))`. As I understood the type’s fingerprint is made in DsBinds#dsEvTypeable by generating a code that makes the fingerprint, so I can’t reuse functions which are already written. My goal is to write a function that makes fingerprints of types which are not type variables such as Int, Maybe Int, ‘[Int] etc. So I tried to follow `mkTrCon` and `mkTrApp` style, and I think I managed to process simple types like Int, Maybe Int — right now I’m processing TyConApp only. But when I tried to make promoted data fingerprint like ‘[Int] I faced some problems. For example, for making `’Just Int` fingerprint first I have to compute 'Just fingerprint by computing 'Just tyCon’s and * fingerprints, then combining them into one fingerprint. Then I have to apply ‘Just to Int. But when I try to do something like that while type checking I cannot separate two cases that match runtime’s`TypeRep (a b)` (a representation for a type application) and `TypeRep a` (a representation for a type constructor) because they are represented by TyConApp. Also I can’t separate tyCon kinds and types for type application because they are merged into one list which is stored in `TyConApp _ [KindOrType]`. [KindOrType] list for `’Just Int` is `[*, Int]`. Is there any way to separate this two cases and kinds/types? Probably there is an easier way to make this function? If not, does type fingerprint function seem possible to make? Any help would be appreciated, Alice.

2 2