- ghc-devs - Haskell.org

classP recently deleted from TH.Lib
by Gabor Greif 19 May '14

19 May '14

The last two commits from (Apr 9) on <https://github.com/ghc/packages-template-haskell/commits/master/Language/Ha…> removed a helper to construct applied type class constraints (`classP`). Some packages (notably `llvm-general-pure`) though, depend on it. Can we add back something like this: {{{ classP :: Name -> [Q Type] -> Q Pred classP cla tys = do tysl <- sequence tys return (foldl' AppT (ConT cla) tysl) }}} and export it again? Or is there such a helper with a different name already? Cheers, Gabor

7 10

Non-exhaustive pattern-match warning in code-example from "Dependently Typed Programming with Singletons"
by Herbert Valerio Riedel 19 May '14

19 May '14

Hello *, I've been experimenting with the code from the "Dependently Typed Programming with Singletons" paper[1] from the following is derived (modulo some irrelevant renamings): {-# LANGUAGE TypeOperators, DataKinds, GADTs, TypeFamilies #-} module CheckedList where data Nat = Z | S Nat data SNat n where SZ :: SNat Z SS :: SNat n -> SNat (S n) infixr 5 :- data List l t where Nil :: List Z t (:-) :: t -> List l t -> List (S l) t type family n1 :< n2 where m :< Z = False Z :< (S m) = True (S n) :< (S m) = n :< m index :: (i :< l) ~ True => List l t -> SNat i -> t index (x :- _) SZ = x index (_ :- xs) (SS i) = index xs i The problem, though, is that with the code above GHC 7.8.2 emits a warning for the `index` function: ,---- | Pattern match(es) are non-exhaustive | In an equation for ‘index’: Patterns not matched: Nil _ `---- So I would have expected to workaround that by explicitly wrapping the length-phantom with the promoted `S` type-constructor, like so index :: (i :< S l) ~ True => List (S l) t -> SNat i -> t index (x :- _) SZ = x index (_ :- xs) (SS i) = index xs i While this would probably have silenced the pattern-match warning, I now get a type-checking error I can't seem to get rid of: ,---- | Could not deduce (l1 ~ 'S l0) from the context ((i :< 'S l) ~ 'True) | bound by the type signature for | index :: (i :< 'S l) ~ 'True => List ('S l) t -> SNat i -> t | | or from ('S l ~ 'S l1) | bound by a pattern with constructor | :- :: forall t (l :: Nat). t -> List l t -> List ('S l) t, | in an equation for ‘index’ | | or from (i ~ 'S n) | bound by a pattern with constructor | SS :: forall (n :: Nat). SNat n -> SNat ('S n), | in an equation for ‘index’ | | ‘l1’ is a rigid type variable bound by | a pattern with constructor | :- :: forall t (l :: Nat). t -> List l t -> List ('S l) t, | in an equation for ‘index’ | | Expected type: List ('S l0) t | Actual type: List l1 t | Relevant bindings include | xs :: List l1 t | | In the first argument of ‘index’, namely ‘xs’ | In the expression: index xs i `---- Is there a way to tweak the code so that GHC doesn't think there's a non-exhaustive pattern-match? Cheers, HVR [1]: http://www.cis.upenn.edu/~eir/papers/2012/singletons/paper.pdf

3 3

RE: [commit: ghc] master: Extract derived constants from nm output for various OSes differently. (3df1c51)
by Simon Peyton Jones 19 May '14

19 May '14

Christian (and all ghc-devs) Thank you working so hard on this. I really appreciate it. But can I beg you to add a Note to explain the issue, and to refer directly to Trac #8783. The ticket has a string of forty-four comments, so presumably it's not a simple, obvious typo. What I fear is that in 5 yrs time someone will say "oh, there's a simpler way of doing this" and will un-do all your good work. Everyone: I'm know I get repetitive about this, but please always think about whether your change will seem as limpidly clear and obvious in five years time as it does now. ALWAYS add a reference to the ticket, unless you are simply fixing a totally stupid typo that nobody could possibly un-fix. (Stuff in the commit message is not enough, because you don't see it when you are looking at the source code. I enthusiastically encourage you to use the "Note" style, which you will see littered all over the compiler these days.) Pretty much any bug-fix is fixing something that wasn't obvious to the original author! Thank you all for making GHC so good. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 19 May 2014 06:11 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Extract derived constants from nm output | for various OSes differently. (3df1c51) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/3df1c5109a6bd2a522717e524c10d8 | 42d4cd8ab8/ghc | | >--------------------------------------------------------------- | | commit 3df1c5109a6bd2a522717e524c10d842d4cd8ab8 | Author: Christian Maeder <Christian.Maeder(a)dfki.de> | Date: Thu Apr 3 10:00:07 2014 +0200 | | Extract derived constants from nm output for various OSes | differently. | | Fixes #8783. | | In order to avoid querying the nm version that does not work on Mac | OS X | we use the "nm -P" output that is supposed to produce (more | portable) | POSIX output and works on all tested OSes (MinGW, Mac OS X, Solaris | and | Linux using GNU nm) although slightly different (as documented). The | "nm | -P" output is actually only needed to recognize the output of a non- | GNU | Solaris nm (all other OSes produce sane outut using "nm" only). | | Signed-off-by: Austin Seipp <austin(a)well-typed.com> | | | >--------------------------------------------------------------- | | 3df1c5109a6bd2a522717e524c10d842d4cd8ab8 | utils/deriveConstants/DeriveConstants.hs | 37 +++++++++++++------------ | ------- | 1 file changed, 15 insertions(+), 22 deletions(-) | | diff --git a/utils/deriveConstants/DeriveConstants.hs | b/utils/deriveConstants/DeriveConstants.hs | index 8c943f0..6bfce24 100644 | --- a/utils/deriveConstants/DeriveConstants.hs | +++ b/utils/deriveConstants/DeriveConstants.hs | @@ -641,7 +641,7 @@ getWanted verbose tmpdir gccProgram gccFlags | nmProgram | oFile = tmpdir </> "tmp.o" | writeFile cFile cStuff | execute verbose gccProgram (gccFlags ++ ["-c", cFile, "-o", | oFile]) | - xs <- readProcess nmProgram [oFile] "" | + xs <- readProcess nmProgram ["-P", oFile] "" | let ls = lines xs | ms = map parseNmLine ls | m = Map.fromList $ catMaybes ms @@ -710,28 +710,21 @@ | getWanted verbose tmpdir gccProgram gccFlags nmProgram | doWanted (ClosurePayloadMacro {}) = [] | doWanted (FieldTypeGcptrMacro {}) = [] | | - -- parseNmLine parses nm output that looks like | - -- "0000000b C derivedConstantMAX_Vanilla_REG" | + -- parseNmLine parses "nm -P" output that looks like | + -- "derivedConstantMAX_Vanilla_REG C 0000000b 0000000b" (GNU | nm) | + -- "_derivedConstantMAX_Vanilla_REG C b 0" (Mac OS X) | + -- "_derivedConstantMAX_Vanilla_REG C 000000b" (MinGW) | + -- "derivedConstantMAX_Vanilla_REG D 1 b" | (Solaris) | -- and returns ("MAX_Vanilla_REG", 11) | - parseNmLine xs0 = case break (' ' ==) xs0 of | - (x1, ' ' : xs1) -> | - case break (' ' ==) xs1 of | - (x2, ' ' : x3) -> | - case readHex x1 of | - [(size, "")] -> | - case x2 of | - "C" -> | - let x3' = case x3 of | - '_' : rest -> | rest | - _ -> x3 | - in case stripPrefix prefix | x3' of | - Just name -> | - Just (name, size) | - _ -> Nothing | - _ -> Nothing | - _ -> Nothing | - _ -> Nothing | - _ -> Nothing | + parseNmLine line | + = case words line of | + ('_' : n) : "C" : s : _ -> mkP n s | + n : "C" : s : _ -> mkP n s | + [n, "D", _, s] -> mkP n s | + _ -> Nothing | + where mkP r s = case (stripPrefix prefix r, readHex s) of | + (Just name, [(size, "")]) -> Just (name, size) | + _ -> Nothing | | -- If an Int value is larger than 2^28 or smaller | -- than -2^28, then fail. | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Status updates
by Austin Seipp 19 May '14

19 May '14

Hello all, It has been another slow week here, and there wasn't a lot I touched in the tree this week. The primary highlights: * The AMP battle rages on! It turns out the addition of `join` to `Monad` has had some subtle implications for GND/Roles. See here for more: https://www.haskell.org/pipermail/ghc-devs/2014-May/004964.html * Simon is still reviewing the ORF work, as far as I know. Hopefully it will Land Real Soon Now. * Patches! Lots of them! I'm reviewing and merging several of them right now. In particular, all the ones slated for 7.8.3 are up for grabs[1] by me right now, but I do need to double-check some of them e.g. on Windows, to make sure nothing breaks. * Many branches have been deleted. Something like 20-30 of them, I think. Yay! Sorry for the spam to the commits list too, but it was a necessary evil. * I'm working away at some of the bugs. #7602 is building right now, with some nice improvements. That will go into the 7.8.3 branch, so OS X users will get a big performance gain, yay! * Another bug: #8736. I had a patch for this, but this one is tricky to fix because when we load object files, we don't actually know if they're static or dynamic. This is encoded in the interface file, but there are some tricky semantics about what to do in some cases of (legitimately) needing to re-read interface files that are a bit subtle. I'll be trying to revive my patch for this today. Other than that, there really hasn't been a lot to mention. Please, do get down on reviewing some bugs and helping fix them![1] I'm more than willing to help in any way I can. I'd also like some feedback: what do people think about the current list? Are there any of you readers who see one *you* think is truly critical? Maybe we can get some input to help narrow the scope if needed. Thanks! [1] https://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&statu… -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

TypeLits vs. Z|Sn naturals
by Herbert Valerio Riedel 18 May '14

18 May '14

Hello again, ...while experimenting with TypeLits I stumbled over the following simple case failing to type-check with GHC 7.8.2: {-# LANGUAGE DataKinds, GADTs #-} data List l t where Nil :: List 0 t Cons :: { lstHead :: t, lstTail :: List l t } -> List (l+1) t with the error message ,---- | Could not deduce (l1 ~ l) from the context ((l + 1) ~ (l1 + 1)) | bound by a pattern with constructor | Cons :: forall t (l :: Nat). t -> List l t -> List (l + 1) t, | in an equation for ‘lstTail’ | | ‘l1’ is a rigid type variable bound by | a pattern with constructor | Cons :: forall t (l :: Nat). t -> List l t -> List (l + 1) t, | in an equation for ‘lstTail’ | | ‘l’ is a rigid type variable bound by | the type signature for lstTail :: List (l + 1) t -> List l t | | Expected type: List l t | Actual type: List l1 t | Relevant bindings include | lstTail :: List l1 t | lstTail :: List (l + 1) t -> List l t | | In the expression: lstTail | In an equation for ‘lstTail’: | lstTail (Cons {lstTail = lstTail}) = lstTail `---- While the code below happily type-checks: {-# LANGUAGE DataKinds, GADTs #-} data Nat = Z | S Nat data List l t where Nil :: List Z t Cons :: { lstHead :: t, lstTail :: List n t } -> List (S n) t Is this a known issue with the TypeLit solver? Cheers, hvr

3 2

Question about Roles and the AMP work
by Austin Seipp 15 May '14

15 May '14

Hello all, While picking the AMP patch back up, it is almost ready to go, but I got quite a puzzling error when attempting to build 'haskeline' with the AMP changes. I don't seem to remember encountering this error before - but maybe my mind is hazy. The error in question is this: https://gist.github.com/thoughtpolice/6df4c70d8a8fb711b282 The TL;DR is that the move of `join` into base has caused a problem here. The error really speaks for itself: GND tries to derive an instance of `join` for DumbTerm, which would have the type join :: DumbTerm m (DumbTerm m a) -> DumbTerm m a and be equivalent to join for StateT. But this can't hold: DumbTerm should unwrap directly to StateT (by newtype equality) and thus the third parameter to StateT in this case is `DumbTerm m a` if you expand the types - but because this argument is Nominal, it cannot unify with 'PosixT m', which is the actual definition of DumbTerm in the first place! With a little thought, this error actually seems reasonable. But it puzzles me as to what we should do now. One thing we could do is just write the instances manually, of course. But that's a bit annoying. Another alternative (and also unfortunate) change is to leave `join` out of Monad, in which case the GND mechanism is oblivious to it and does not need to worry about deriving these cases. I am not sure how many packages depend on using GND to derive monads like StateT with Nominal arguments, but I imagine it is not totally insignificant and will essentially hurt a lot of people who may use it. Richard, I'm particularly interested to hear what you think. This one sort of snuck up! (NB: despite this, the AMP work is very close to landing in HEAD, at which point we can begin cleaning stuff up faster.) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 3

Many new validate failures, "Synonym in TyConAppCo"-related
by Joachim Breitner 13 May '14

13 May '14

Hi, I suddenly get Unexpected failures: gadt T7294 [exit code non-0] (normal) indexed-types/should_compile GADT1 [exit code non-0] (normal) indexed-types/should_compile GADT11 [exit code non-0] (normal) indexed-types/should_compile GADT3 [exit code non-0] (normal) indexed-types/should_compile IndTypesPerf [bad exit code] (normal) indexed-types/should_compile NonLinearLHS [exit code non-0] (normal) indexed-types/should_compile Numerals [exit code non-0] (normal) indexed-types/should_compile Roman1 [exit code non-0] (normal) indexed-types/should_compile Simple9 [exit code non-0] (normal) indexed-types/should_compile T2219 [exit code non-0] (normal) indexed-types/should_compile T2627 [exit code non-0] (normal) indexed-types/should_compile T3484 [exit code non-0] (normal) indexed-types/should_compile T4935 [exit code non-0] (normal) indexed-types/should_compile T7585 [exit code non-0] (normal) indexed-types/should_fail T2664a [exit code non-0] (normal) polykinds PolyKinds10 [exit code non-0] (normal) polykinds PolyKinds12 [exit code non-0] (normal) polykinds T6002 [exit code non-0] (normal) simplCore/should_compile T5329 [exit code non-0] (normal) simplCore/should_run T5315 [exit code non-0] (optasm) typecheck/should_compile T5490 [exit code non-0] (normal) typecheck/should_compile T7196 [exit code non-0] (normal) after these three changes were pushed: Changes to ghc: commit 214ad2d24cda4aaef541df3e213d5c4845f95c71 Author: Peter Trommler <ptrommler(a)scm.org> Date: Wed Apr 30 11:41:51 2014 +0200 Fix globalRegMaybe for unregisterised build. In commit 83a003f globalRegMaybe will be called but panics for unregisterised compilers. In an unregisterised compiler there are no global registers so always return `Nothing`. Fixes #9055. commit 21f17d06aa5c33e639f1b0d37b4bf888b494c441 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue May 13 13:17:19 2014 +0100 Fix invariant in mkAppCoFlexible mkAppCoFlexible was breaking the invariant that the head of a TyConAppCo cannot be a type synonym. This small patch fixes it. commit 4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue May 13 13:15:45 2014 +0100 Lint should check that TyConAppCo doesn't have a synonym in the tycon position That is why Lint didn't nail Trac #9102 Full log at https://s3.amazonaws.com/archive.travis-ci.org/jobs/25063931/log.txt. It seems that most, if not all, fail with a "Synonym in TyConAppCo" lint error. If Lint is correct here, then this may indicate further bugs are around. But in that case the correct thing would be to have a ticket number for that problem and mark all failing test cases as expect_broken – it’s the only sensible way of having an always succeeding test suite in master. So is the Lint check correct and this uncovered one or more bugs here, or is the Lint check actually too restrictive? Greetings, Joachim Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

4 3

Re: [commit: ghc] master: Revert "Per-thread allocation counters and limits" (f0fcc41)
by Karel Gardas 13 May '14

13 May '14

Hello Simon, I'm sorry to disturb you, but I've noticed that your revert patch below contains this change: diff --git a/includes/CodeGen.Platform.hs b/includes/CodeGen.Platform.hs index f3abb3d..3d6dd41 100644 --- a/includes/CodeGen.Platform.hs +++ b/includes/CodeGen.Platform.hs @@ -741,8 +741,10 @@ globalRegMaybe CurrentTSO = Just (RealRegSingle REG_CurrentTSO) # ifdef REG_CurrentNursery globalRegMaybe CurrentNursery = Just (RealRegSingle REG_CurrentNursery) # endif -#endif globalRegMaybe _ = Nothing +#else +globalRegMaybe = panic "globalRegMaybe not defined for this platform" +#endif and I'm not sure if this is intentional or just overlooked addition. The problem with this line is that it causes stage1 panic on unregisterised build on PPC64 platform: http://haskell.inf.elte.hu/builders/linux-ppc64-head/41/10.html and we have not had such panic before the patch: http://haskell.inf.elte.hu/builders/linux-ppc64-head/31/10.html -- well, you see that dll-split segfaults, but at least ghc-stage1 is proved to work well here. Kudos to Gabor Pali who spotted this on PPC64 builder... Thanks! Karel On 05/ 4/14 11:45 PM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/f0fcc41d755876a1b02d1c7c79f575150… > >> --------------------------------------------------------------- > > commit f0fcc41d755876a1b02d1c7c79f57515059f6417 > Author: Simon Marlow<marlowsd(a)gmail.com> > Date: Sun May 4 20:27:42 2014 +0100 > > Revert "Per-thread allocation counters and limits" > > Problems were found on 32-bit platforms, I'll commit again when I have a fix. > > This reverts the following commits: > 54b31f744848da872c7c6366dea840748e01b5cf > b0534f78a73f972e279eed4447a5687bd6a8308e > > >> --------------------------------------------------------------- > > f0fcc41d755876a1b02d1c7c79f57515059f6417 > compiler/cmm/CmmLayoutStack.hs | 9 +- > compiler/codeGen/StgCmmForeign.hs | 268 ++++++--------------- > includes/CodeGen.Platform.hs | 4 +- > includes/rts/Constants.h | 6 - > includes/rts/Flags.h | 8 - > includes/rts/Threads.h | 8 +- > includes/rts/storage/TSO.h | 31 +-- > libraries/base/Control/Exception.hs | 1 - > libraries/base/Control/Exception/Base.hs | 1 - > libraries/base/GHC/Conc.lhs | 6 - > libraries/base/GHC/Conc/Sync.lhs | 92 +------ > libraries/base/GHC/IO/Exception.hs | 21 +- > rts/HeapStackCheck.cmm | 4 +- > rts/Linker.c | 4 - > rts/Prelude.h | 2 - > rts/RaiseAsync.c | 54 ----- > rts/RaiseAsync.h | 4 - > rts/RtsFlags.c | 10 - > rts/RtsStartup.c | 1 - > rts/Schedule.c | 19 -- > rts/Threads.c | 77 +++--- > rts/package.conf.in | 2 - > rts/sm/Storage.c | 6 - > rts/win32/libHSbase.def | 1 - > testsuite/tests/concurrent/should_run/all.T | 7 - > .../tests/concurrent/should_run/allocLimit1.hs | 9 - > .../tests/concurrent/should_run/allocLimit1.stderr | 1 - > .../tests/concurrent/should_run/allocLimit2.hs | 17 -- > .../tests/concurrent/should_run/allocLimit3.hs | 15 -- > .../tests/concurrent/should_run/allocLimit3.stderr | 1 - > .../tests/concurrent/should_run/allocLimit3.stdout | 1 - > .../tests/concurrent/should_run/allocLimit4.hs | 31 --- > utils/deriveConstants/DeriveConstants.hs | 1 - > 33 files changed, 144 insertions(+), 578 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc f0fcc41d755876a1b02d1c7c79f57515059f6417 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 3

Loading package integer-gmp ... <command line>: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)
by Mateusz Kowalczyk 12 May '14

12 May '14

Hi, Trying to compile GHC in the source tree on NixOS and meeting with failure with: "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... <command line>: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory) While libgmp isn't anywhere obvious, below is my build.mk and content of the pointed-to directories. Am I missing something here? Is something ignoring the configure option maybe? [shana@lenalee:~/programming/ghc/mk]$ cat build.mk libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-libraries=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-includes=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include DYNAMIC_BY_DEFAULT = NO [shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib total 604K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r-xr-xr-x 1 root nixbld 949 Jan 1 1970 libgmp.la lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so -> libgmp.so.10.1.3 lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so.10 -> libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 556K Jan 1 1970 libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 1.1K Jan 1 1970 libgmpxx.la lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so -> libgmpxx.so.4.3.3 lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so.4 -> libgmpxx.so.4.3.3 -r-xr-xr-x 1 root nixbld 30K Jan 1 1970 libgmpxx.so.4.3.3 [shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include total 204K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r--r--r-- 1 root nixbld 78K Jan 1 1970 gmp.h -r--r--r-- 1 root nixbld 114K Jan 1 1970 gmpxx.h -- Mateusz K.

2 10

Fwd: Question about Roles and the AMP work
by Benno Fünfstück 12 May '14

12 May '14

I'm not familar with the internals of GHC, but maybe it would be possible for GHC to just use the default definition for `join` in the case that deriving fails because of roles? At least if the class to be derived has a `MINIMAL` pragma, GHC could check if that is still satisfied even without the method that failed to derive, and use the default definition if that's the case. 2014-05-12 17:28 GMT+02:00 Edward Kmett <ekmett(a)gmail.com>: As a straw man, if we went to a typeclass-driven 'next arg is > representational' approach then we could possibly recover 'join' here. > > e.g. > > class Representational f where > rep :: Coercion f g -> Coercion a b -> Coercion (f a) (g b) > > class Representational f => Phantom f where > phantom :: Coercion f g -> Coercion (f a) (g b) > > When we look at for the constraint head Coercible (f a) (g b) we'd then > check for Phantom f and if so look for Coercible f g, or fall back to Representational > f, and look for Coercible f g and Coercible a b. > > Then to derive GND for C m it'd need to check Representational m due to > the type of join needing m's next arg to be representational, find it and > move on. > > The set of these instances can be left open like any other typeclass and > users could supply their own for tricky conversions if need be. > > If you just wrote the existing role annotations, but let them request > currently impossible roles you could use the desired role to infer the > constraints involved. > > e.g. > > newtype StateT s m a = StateT { runStateT :: s -> m (a, s) } > > should be able to derive something like > > instance Representational (StateT s) > instance Representational m => Representational (StateT s m) > instance Phantom m => Phantom (StateT s m) > > If we put nominal or representational on the m argument > > type role StateT nominal nominal nominal > > then we could just elide the instances for anything lower in the nominal > -> representational -> phantom lattice than the named role. > > The positional argument scheme isn't perfect, as in the above it'd fail to > let you derive `instance Representational StateT` due to the s occurring > under m, an argument later in the argument list, but it does fix most of > the problems with Coercible and monad transfomers. > > There might be some fancier form that can cover all of the use cases, but > I'm not seeing it off hand. > > -Edward > > > On Tue, May 13, 2014 at 12:59 AM, Simon Peyton Jones < > simonpj(a)microsoft.com> wrote: > >> This looks a bit awkward to me. Here's a small test case >> >> class C m where >> ret :: a -> m a >> bind :: m a -> (a -> m b) -> m b >> join :: m (m a) -> m a >> >> newtype T m a = MkT (m a) deriving( C ) >> >> This is accepted without the 'join' in the class, but rejected with it. >> >> So *all* uses of GND to do 'deriving( Monad )' will break when 'join' is >> added to Monad. >> >> And this is because we don't know that 'm' ranges only over things that >> have representational arguments; type variables always have nominal >> arguments. The paper draws attention to this shortcoming, but now it's >> becoming important. >> >> I can't think of an obvious workaround either, except not putting 'join' >> in Monad. >> >> Simon >> >> >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of >> Austin >> | Seipp >> | Sent: 12 May 2014 13:53 >> | To: ghc-devs(a)haskell.org >> | Subject: Question about Roles and the AMP work >> | >> | Hello all, >> | >> | While picking the AMP patch back up, it is almost ready to go, but I got >> | quite a puzzling error when attempting to build 'haskeline' with the AMP >> | changes. I don't seem to remember encountering this error before - but >> | maybe my mind is hazy. >> | >> | The error in question is this: >> | >> | https://gist.github.com/thoughtpolice/6df4c70d8a8fb711b282 >> | >> | The TL;DR is that the move of `join` into base has caused a problem >> | here. The error really speaks for itself: GND tries to derive an >> | instance of `join` for DumbTerm, which would have the type >> | >> | join :: DumbTerm m (DumbTerm m a) -> DumbTerm m a >> | >> | and be equivalent to join for StateT. But this can't hold: DumbTerm >> | should unwrap directly to StateT (by newtype equality) and thus the >> | third parameter to StateT in this case is `DumbTerm m a` if you expand >> | the types - but because this argument is Nominal, it cannot unify with >> | 'PosixT m', which is the actual definition of DumbTerm in the first >> | place! >> | >> | With a little thought, this error actually seems reasonable. But it >> | puzzles me as to what we should do now. One thing we could do is just >> | write the instances manually, of course. But that's a bit annoying. >> | >> | Another alternative (and also unfortunate) change is to leave `join` out >> | of Monad, in which case the GND mechanism is oblivious to it and does >> | not need to worry about deriving these cases. >> | >> | I am not sure how many packages depend on using GND to derive monads >> | like StateT with Nominal arguments, but I imagine it is not totally >> | insignificant and will essentially hurt a lot of people who may use it. >> | >> | Richard, I'm particularly interested to hear what you think. This one >> | sort of snuck up! >> | >> | (NB: despite this, the AMP work is very close to landing in HEAD, at >> | which point we can begin cleaning stuff up faster.) >> | >> | -- >> | Regards, >> | >> | Austin Seipp, Haskell Consultant >> | Well-Typed LLP, http://www.well-typed.com/ >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs(a)haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >

1 0