Re: Associated type instances
Simon, I’m not sure when this ”feature” was added, but I’m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones simo...@microsoft.com: Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x - b That is just what you’d expect. But currently this is allowed too: instance C [x] where type T [x] Int = x - Int type T [x] Bool = Bool - x That is, GHC 7.8 allows many associated type instances, provided they don’t overlap. But, oddly you can’t further instantiate the instance pattern. This would make just as much sense, but isn’t allowed: instance C [x] where type T [Int] b = b - Int type T [Bool] b = Bool - b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x - x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x - x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it’s a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: · The “shared arguments” of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is “shared”; and in class D, the second argument position of S is shared. · A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions · For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration ___ 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: Associated type instances
I'm not sure when this feature was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting! But I'm just checking that no one has meanwhile become addicted to it. Simon From: Manuel Chakravarty [mailto:mchakrava...@me.com] Sent: 24 June 2014 08:54 To: Simon Peyton Jones Cc: GHC List; ghc-devs@haskell.org Subject: Re: Associated type instances Simon, I'm not sure when this feature was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com: Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x - b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x - Int type T [x] Bool = Bool - x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b - Int type T [Bool] b = Bool - b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x - x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x - x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The shared arguments of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is shared; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration ___ ghc-devs mailing list ghc-devs@haskell.orgmailto: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: Pruning GADT case alternatives with uninhabitable coercion parameters
Conal This also relates to detecting redundant or overlapped patterns in source programs. I know that Dimitrios is looking at this with Tom, Nikolas, George who I’m cc’ing him. I think their current approach may be to integrate the overlap checking with the constraint solver in the type checker. But that isn’t going to work for optimising Core. An alternative approach would be to implement a specialised constraint solver. It could be MUCH simpler than the one in the inference engine, because (a) there are no unification variables to worry about, (b) there is no need to gather evidence. More or less it’s task could be to answer the question IsC |- Ddefinitely a contradiction? where C are the “given” constraints (from enclosing pattern matches) and D are the “wanted” constraints (from the current pattern match that may be unreachable). I don’t think it would be hard to implement such a function. I’d be happy to help advise if someone wants to take it on. Dimitrios: If we had such a function, then maybe it’d be better to use it for the pattern-matching overlap detection too? Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 20 June 2014 18:59 To: ghc-devs@haskell.org Subject: Pruning GADT case alternatives with uninhabitable coercion parameters I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: case ds of wild (Sum Int) L (~# :: S (S Z) ~N Z) a1 - f a1 B n1 (~# :: S (S Z) ~N S n1) uv - ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up: case ds0 of wild0 (Sum Int) L (~# :: n1 ~N Z) a1 - f0 a1 B n2 (~# :: n1 ~N S n2) uv0 - ... Now I want to remove the first `L` alternative with `n1 ~ Z`, given that the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` alternative), so that `n1 ~ S Z`. With more inlining, more such equalities pile up. Soon we get to an impossible `B` alternative, whose removal would then eliminate the rest of the recursive unfolding. My questions: * Does this sort of transformation already live in GHC somewhere, and if so, where? * Are there gotchas / sources of unsoundness in the transformation I'm suggesting? * Is anyone else already working on this sort of transformation? -- Conal ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Pruning GADT case alternatives with uninhabitable coercion parameters
we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can’t assess very well yet if this is a real problem though That is a very good point. Nevertheless, given · the typechecked HsSyn (i.e. still in source form, but with type inference fully completed · the independent contradiction-detector described below (which is independent of whether the contradiction problems it is given come from HsSyn or Core) it would be easy to give source-localised error messages Simon From: Dimitrios Vytiniotis Sent: 24 June 2014 11:58 To: Simon Peyton Jones; Conal Elliott; ghc-devs@haskell.org Cc: Nikolaos S. Papaspyrou (nic...@softlab.ntua.gr); George Karachalias Subject: RE: Pruning GADT case alternatives with uninhabitable coercion parameters Yes it would be better in the sense that we don’t really want to be dealing with unification variables and evidence when we simply use the constraint solver to detect inconsistencies in possibly missing patterns, but the concern has been that if we are already desugared and in core maybe we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can’t assess very well yet if this is a real problem though … In general I agree that a simple constraint solver for Core might be an independently useful tool for this kind of optimization. (I think George had thought about this too). Thanks! d- From: Simon Peyton Jones Sent: Tuesday, June 24, 2014 11:41 AM To: Conal Elliott; ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Cc: Dimitrios Vytiniotis; Nikolaos S. Papaspyrou (nic...@softlab.ntua.grmailto:nic...@softlab.ntua.gr); George Karachalias; Simon Peyton Jones Subject: RE: Pruning GADT case alternatives with uninhabitable coercion parameters Conal This also relates to detecting redundant or overlapped patterns in source programs. I know that Dimitrios is looking at this with Tom, Nikolas, George who I’m cc’ing him. I think their current approach may be to integrate the overlap checking with the constraint solver in the type checker. But that isn’t going to work for optimising Core. An alternative approach would be to implement a specialised constraint solver. It could be MUCH simpler than the one in the inference engine, because (a) there are no unification variables to worry about, (b) there is no need to gather evidence. More or less it’s task could be to answer the question IsC |- Ddefinitely a contradiction? where C are the “given” constraints (from enclosing pattern matches) and D are the “wanted” constraints (from the current pattern match that may be unreachable). I don’t think it would be hard to implement such a function. I’d be happy to help advise if someone wants to take it on. Dimitrios: If we had such a function, then maybe it’d be better to use it for the pattern-matching overlap detection too? Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 20 June 2014 18:59 To: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Subject: Pruning GADT case alternatives with uninhabitable coercion parameters I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: case ds of wild (Sum Int) L (~# :: S (S Z) ~N Z) a1 - f a1 B n1 (~# :: S (S Z) ~N S n1) uv - ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up: case ds0 of wild0 (Sum Int) L (~# :: n1 ~N Z) a1 - f0 a1 B n2 (~# :: n1 ~N S n2) uv0 - ... Now I want to remove the first `L` alternative with `n1 ~ Z`, given that the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` alternative), so that `n1 ~ S Z`. With more inlining, more such equalities pile up. Soon we get to an impossible `B` alternative, whose removal would then eliminate the rest of the recursive unfolding. My questions: * Does this sort of transformation already live in GHC somewhere, and if so, where? * Are there gotchas / sources of unsoundness in the transformation I'm suggesting? * Is anyone else already working on this sort of transformation? -- Conal ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Help needed: parsing pattern synonym contexts
Hi,
I'm working on adding type signatures to pattern synonyms. The syntax I'm
after would look something like, e.g.:
pattern (Eq b) = P Int (Bool, b) (f [a]) :: (Show a) = Maybe [a]
My problem is with parsing the two contexts. I wrote the parser in the
following way, which I felt natural (actions omitted for brevity)
pattern_synonym_sig :: { LSig RdrName }
: 'pattern' patsyn_context patsyn_stuff '::' patsyn_context type
patsyn_stuff :: { Located (Located RdrName, HsPatSynDetails (LHsType
RdrName)) }
: constr_stuff
patsyn_context :: { LHsContext RdrName }
: {- empty -}
| forall context '='
However, this doesn't work, no matter if those contexts are present or
not. If I remove both contexts from the rules, i.e. if I replace
pattern_synonym_sig with
: 'pattern' patsyn_stuff '::' type
then parsing succeeds when there are no contexts on either side. I've also
tried
: 'pattern' patsyn_stuff '::' ctype
with the intention of recovering the required context from the ctype (and
I could do similar tricks to get the provided context from the
patsyn_stuff by using a modified version of constr_stuff); however, even
that doesn't work as I expected it, i.e. with this latter version, this:
pattern Single a :: (Eq a) = [a]
fails with a parse error on ::.
Can someone help me out here please?
Thanks,
Gergo
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: CmmLint error when doing safe ccall from cmm
On 20/06/2014 22:23, Yuras Shumovich wrote:
Simon,
Sorry if I'm too stupid, but
do you mean we only support 64-bit results from prim call? But I'm
using TO_W_ macro to convert the result to 64-bit value before returning
from cmm function.
The result of your foreign call is a CInt, which is an I32. If you make
it an I64 and then convert it to an I32, that should work.
Cheers,
Simon
Or you mean result from ccall call?
nativeGen/X86/CodeGen.hs:genCCall64 definitely supports that. And it
works for unsafe ccall.
Looks like the issue is somewhere in translation from high level cmm to
low level cmm.
Thanks,
Yuras
On Fri, 2014-06-20 at 21:24 +0100, Simon Marlow wrote:
On 20/06/14 15:03, Yuras Shumovich wrote:
Hello,
I'm trying to do safe ccall from cmm (see below for the code). It seems
to work, but -dcmm-lint is not satisfied:
/opt/ghc-7.8.2/bin/ghc --make -o test hs.hs cmm.cmm c.c -dcmm-lint
-fforce-recomp
Cmm lint error:
in basic block c4
in assignment:
_c1::I32 = R1;
Reg ty: I32
Rhs ty: I64
Program was:
{offset
c5: _c0::I64 = R1;
_c2::I64 = c_test;
_c3::I32 = %MO_UU_Conv_W64_W32(_c0::I64);
I64[(youngc4 + 8)] = c4;
foreign call ccall arg hints: [] result hints: []
(_c2::I64)(...) returns to c4 args: ([_c3::I32]) ress: ([_c1::I32])ret_args: 8ret_off: 8;
c4: _c1::I32 = R1;
R1 = %MO_SS_Conv_W32_W64(_c1::I32);
call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8;
}
no location info:
Compilation had errors
I believe we only support 64-bit results on a 64-bit platform, but we
you can always narrow to 32 bits with an MO_Conv afterwards if you want.
This is essentially what happens when you call a function that returns
CInt using the FFI - you can always try that and see what Cmm you get.
Also, I'll be mildly surprised if using safe foreign calls from
hand-written Cmm works, since I don't believe we use them anywhere so it
isn't likely to be well tested :-)
Cheers,
Simon
The same code without safe annotation passes cmm lint. Is it my error
or ghc bug? How can I do safe ccall in cmm correctly?
Here is the code:
== c.c ==
#include assert.h
int c_test(int i)
{
assert(i == 1);
return 2;
}
== cmm.cmm
#include Cmm.h
cmm_test(W_ i)
{
CInt i1;
(i1) = ccall c_test(W_TO_INT(i)) safe;
return (TO_W_(i1));
}
== hs.hs ==
{-# LANGUAGE GHCForeignImportPrim #-}
{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE UnboxedTuples #-}
{-# LANGUAGE UnliftedFFITypes #-}
import GHC.Prim
import GHC.Types
import Control.Exception
foreign import prim cmm_test test :: Int# - Int#
main :: IO ()
main = do
let i1 = test 1#
assert (I# i1 == 2) (return ())
Thanks,
Yuras
___
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: Phabricator for patches and code review
I find the automatic squashing to rather harmful to the commit history. So if you have several nice commits that you want to send for review, don't use arc land to commit them, as it will ruin the history. Instead git push them as per normal and use `arc close` (IIRC) to close the code review. I also find it useful to remove lots of the arc gunk that was added to the commit message, to not pollute our revision history with data from some specific tool. On Tue, Jun 24, 2014 at 4:09 PM, Richard Eisenberg e...@cis.upenn.edu wrote: Thanks so much for writing this! I have some questions: 1) I'm just setting things up on my machine. It says to `arc install-certificate` in my GHC directory. Is it important precisely which clone of GHC my directory is set up against? For example, my pull origin is git://git.haskell.org/ghc.git and my push origin is ssh:// g...@git.haskell.org/ghc.git. Is this the right set-up? If this bit matters, could you add it to the page? Or, if not, could you comment on what `arc` is pulling from the ghc directory? 2) I'm confused about what, precisely, `arc diff` does. You describe that it updates the review available online. Does that reference some git commits? Do I need to push by `wip` branch before `arc diff`ing? Do I *never* need to push my branch, because `arc diff` pushes it for me? Do I *never* need to push my branch, because Phab uses other ways of moving the code around? For better or worse, I tend to keep my branches local until I'm ready to merge with master, and I want to know if this needs to change. 3) You say A change cannot be merged until at least one reviewer has signed off. Does this mean merged with ghc-7.8 (or whatever the current stable branch is)? Or does it mean merged with master? The former is the status quo, but with a new route, so to speak. The latter is something new, as several of us push directly to `master` without a review. I'm not against such a change, per se, just trying to understand it. 4) Is it now compulsory to use Phab when contributing? This page makes it sound that way. Again, no complaints -- just trying to understand it. 5) The page says to add `austin` as a reviewer. I would expect `thoughtpolice`. What's up with Phab usernames? Do other people I know and love have Phab usernames distinct from Trac usernames? 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What does the # signify? 7) I'm baffled by Landing reviews. The `arc land` bit is clearer, but I'm still unsure of what my local state and the git upstream state must be beforehand for this to work. Will this ask me for a commit message? Will it use the one I specified to Phab during `arc diff`? In general, I'm confused about how much info `arc` pulls from various places to do its work. I know I could learn by doing, but I'm afraid of mashing on the Phab and/or git history as I do so. 8) Some of the same questions surround `arc patch`: What does my git state need to be for this to work? 9) How do I contribute to others' revisions? Or, will this be obvious what it comes to pass? I realize I've asked a lot here, and it might be too much to expect all of these answers to be on the page. If that's the case, could you perhaps link to relevant manuals or places to learn more? The way `arc` works, in particular, seems like magic; magic is very powerful, but it can be equally dangerous, and so I'd like to learn more. Thanks so much for doing all this! Richard On Jun 23, 2014, at 10:44 AM, Austin Seipp aus...@well-typed.com wrote: Hi all, I went ahead and took some time to write some stuff down about Phabricator, including some basic tips on the workflows and applications here: https://ghc.haskell.org/trac/ghc/wiki/Phabricator It's definitely going to need more expanding. Do let me know if anything is confusing. On Wed, Jun 18, 2014 at 2:38 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Duh, ignore what I wrote. I just realized I'm working on a non-rebased branch :-) Janek Dnia środa, 18 czerwca 2014, Jan Stolarek napisał: I read the friendly Arcanist manual and I wonder if we intend to have a default .arcconfig file in the GHC repo? From the docs it seems like a good idea. Janek Dnia wtorek, 17 czerwca 2014, Simon Marlow napisał: On 13/06/14 10:47, Jan Stolarek wrote: It seems that most people are in favour of using Phabricator for code review. So what are the next steps? Can we just start using the existing phabricator instance? I'm working on some code right now that definitely needs reviewing. You can use it, and a few of us have already been doing so. There isn't any Trac integration yet, but it works nicely for patch review. There's a short intro doc here: https://secure.phabricator.com/book/phabricator/article/differential/ , but it's not hard to figure out the basics, and you'll learn by watching how other people use it. If you
Re: Associated type instances
I'm sure I've used the feature that you're proposing to remove, but I'll adapt. To be clear, the change means no loss of expressiveness, just that I'll sometimes have to use a helper type family (closed or open), right? If I'm right there, then no complaints from me. Richard On Jun 24, 2014, at 4:07 AM, Simon Peyton Jones simo...@microsoft.com wrote: I’m not sure when this ”feature” was added, but I’m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting! But I’m just checking that no one has meanwhile become addicted to it. Simon From: Manuel Chakravarty [mailto:mchakrava...@me.com] Sent: 24 June 2014 08:54 To: Simon Peyton Jones Cc: GHC List; ghc-devs@haskell.org Subject: Re: Associated type instances Simon, I’m not sure when this ”feature” was added, but I’m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones simo...@microsoft.com: Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x - b That is just what you’d expect. But currently this is allowed too: instance C [x] where type T [x] Int = x - Int type T [x] Bool = Bool - x That is, GHC 7.8 allows many associated type instances, provided they don’t overlap. But, oddly you can’t further instantiate the instance pattern. This would make just as much sense, but isn’t allowed: instance C [x] where type T [Int] b = b - Int type T [Bool] b = Bool - b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x - x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x - x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it’s a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: · The “shared arguments” of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is “shared”; and in class D, the second argument position of S is shared. · A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions · For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Phabricator for patches and code review
Richard, Thanks, these are all actually really excellent questions. 1) I'm just setting things up on my machine. It says to `arc install-certificate` in my GHC directory. Is it important precisely which clone of GHC my directory is set up against? For example, my pull origin is git://git.haskell.org/ghc.git and my push origin is ssh://g...@git.haskell.org/ghc.git. Is this the right set-up? If this bit matters, could you add it to the page? Or, if not, could you comment on what `arc` is pulling from the ghc directory? The way 'arc install-certificate' knows what URL to use is based on a file in the GHC repository, called .arcconfig - this tells arcanist where the Phabricator instance is, and what the project callsign is. GHC's copy is here: https://github.com/ghc/ghc/blob/master/.arcconfig So all you need to do is run 'install-certificate' inside the main GHC repo, and you're done! If you've got a copy of HEAD from the past two weeks or so, you should be golden. Once install-certificate is done, it will write the certificate into a file called ~/.arcrc, so you don't have to install it again. 2) I'm confused about what, precisely, `arc diff` does. You describe that it updates the review available online. Does that reference some git commits? Do I need to push by `wip` branch before `arc diff`ing? Do I *never* need to push my branch, because `arc diff` pushes it for me? Do I *never* need to push my branch, because Phab uses other ways of moving the code around? For better or worse, I tend to keep my branches local until I'm ready to merge with master, and I want to know if this needs to change. You _never_ have to push a branch upstream if you don't want to (but if you'd like to keep your changes in a safe place until you merge them, feel free to put them on a wip/* branch!) What 'arc diff' does is this: when you run it, it calculates which commits you have made. It does this by comparing your current git repository to that of the *upstream* repository, the GHC repo. When it calculates the set of commits, 'arc diff' then sends them all for review. When you make a new commit, and say 'arc diff' again, it updates it. 3) You say A change cannot be merged until at least one reviewer has signed off. Does this mean merged with ghc-7.8 (or whatever the current stable branch is)? Or does it mean merged with master? The former is the status quo, but with a new route, so to speak. The latter is something new, as several of us push directly to `master` without a review. I'm not against such a change, per se, just trying to understand it. Not quite. All changes go into master first, after it has been reviewed. Afterwords, they may be picked onto the stable branch by me or Herbert. My only statement is that we cannot merge a patch from Phab to master until at least one person has given it the OK. If you put a review on Phabricator, I believe you should at least wait for one person to review it. That is, after all, what Phabricator is for! :) But note: you are *never* required to use Phabricator for your changes! If your workflow is good for you, I don't want to interrupt it. Instead, I want you to submit reviews so other people can read and understand your work - existing committers *are not* forced to do this. For example Richard, you obviously keep in close touch with Simon, so he's likely aware of your changes and their needs. There's no reason for you to ask SPJ for a review on a change you already have a handle on - just go ahead and push it! 4) Is it now compulsory to use Phab when contributing? This page makes it sound that way. Again, no complaints -- just trying to understand it. Nope! It might be so later (for external contributors without commit access), but I first need to document all the workflows so contributors can get a handle on it. So thanks for being the guinea pig :) But it won't ever be compulsory for all committers. Again, I want people to use Phab so they can have others read, understand, and comment about their work. There's no hard-line rule on if you should or should not submit a review - I will totally trust your judgement as to what you think is your best workflow. 5) The page says to add `austin` as a reviewer. I would expect `thoughtpolice`. What's up with Phab usernames? Do other people I know and love have Phab usernames distinct from Trac usernames? Sorry - I'm the only outlier. I believe every other person has the same username except for me. :P (This is partly due to the fact we use Phabricator for other Haskell.org projects as well, and we didn't explicitly plan to use it for GHC initially - so 'austin' was the name I picked when first setting up the instance). 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What does the # signify? Good question I totally forgot about. In Phabricator, there is a notion of 'projects', which have members. There is a project known as 'GHC', and in Phab, you can refer to
Re: Phabricator for patches and code review
Personally I don't particularly mind the fact Phabricator squashes things and adds onto the URL. For one it means we can always refer to the differential revision solely by the commit itself, as opposed to digging up some history. But also, Phab generally asks you to put some useful information in there. I've found myself to be much more explicit and verbose when filling out Phab commits than most other tools, and meaty, verbose commit messages are very useful IME. As for squashing, there's an argument to be made, I think, that this just requires a little practice to get comfortable with. :) For example, I have a review called D4: https://phabricator.haskell.org/D4 This really adds two separate things: it adds a set of flags to the frontend, and a set of optimizations to the backend (based on the flags). Really, this *should* be two reviews instead of one! The fact that Phabricator wants to squash them into a single commit when landing is a symptom of the problem, not the root problem, I think. So while I may have to fiddle to separate the two later (not really that hard,) I think this was more a case of me putting two unrelated things in one review. In fact it's very regular for GHC developers to squash commits themselves, and I know many of us do exactly that. So I think the main change is just having the tool embody this for us, as opposed to always doing it manually. On Tue, Jun 24, 2014 at 9:27 AM, Johan Tibell johan.tib...@gmail.com wrote: I find the automatic squashing to rather harmful to the commit history. So if you have several nice commits that you want to send for review, don't use arc land to commit them, as it will ruin the history. Instead git push them as per normal and use `arc close` (IIRC) to close the code review. I also find it useful to remove lots of the arc gunk that was added to the commit message, to not pollute our revision history with data from some specific tool. On Tue, Jun 24, 2014 at 4:09 PM, Richard Eisenberg e...@cis.upenn.edu wrote: Thanks so much for writing this! I have some questions: 1) I'm just setting things up on my machine. It says to `arc install-certificate` in my GHC directory. Is it important precisely which clone of GHC my directory is set up against? For example, my pull origin is git://git.haskell.org/ghc.git and my push origin is ssh://g...@git.haskell.org/ghc.git. Is this the right set-up? If this bit matters, could you add it to the page? Or, if not, could you comment on what `arc` is pulling from the ghc directory? 2) I'm confused about what, precisely, `arc diff` does. You describe that it updates the review available online. Does that reference some git commits? Do I need to push by `wip` branch before `arc diff`ing? Do I *never* need to push my branch, because `arc diff` pushes it for me? Do I *never* need to push my branch, because Phab uses other ways of moving the code around? For better or worse, I tend to keep my branches local until I'm ready to merge with master, and I want to know if this needs to change. 3) You say A change cannot be merged until at least one reviewer has signed off. Does this mean merged with ghc-7.8 (or whatever the current stable branch is)? Or does it mean merged with master? The former is the status quo, but with a new route, so to speak. The latter is something new, as several of us push directly to `master` without a review. I'm not against such a change, per se, just trying to understand it. 4) Is it now compulsory to use Phab when contributing? This page makes it sound that way. Again, no complaints -- just trying to understand it. 5) The page says to add `austin` as a reviewer. I would expect `thoughtpolice`. What's up with Phab usernames? Do other people I know and love have Phab usernames distinct from Trac usernames? 6) Who is the reviewer `#ghc`? Is this related to the IRC channel? What does the # signify? 7) I'm baffled by Landing reviews. The `arc land` bit is clearer, but I'm still unsure of what my local state and the git upstream state must be beforehand for this to work. Will this ask me for a commit message? Will it use the one I specified to Phab during `arc diff`? In general, I'm confused about how much info `arc` pulls from various places to do its work. I know I could learn by doing, but I'm afraid of mashing on the Phab and/or git history as I do so. 8) Some of the same questions surround `arc patch`: What does my git state need to be for this to work? 9) How do I contribute to others' revisions? Or, will this be obvious what it comes to pass? I realize I've asked a lot here, and it might be too much to expect all of these answers to be on the page. If that's the case, could you perhaps link to relevant manuals or places to learn more? The way `arc` works, in particular, seems like magic; magic is very powerful, but it can be equally dangerous, and so I'd like to learn more. Thanks so much for doing all this! Richard On
RE: Help needed: parsing pattern synonym contexts
What do you mean by doesn't work? Crashes? Fails to build with some error?
Builds but doesn't parse what you expect?
In the latter case, what happened to the shift/reduce and reduce/reduce errors
reported by Happy? Esp the latter. If you are getting more you need to track
them down.
For exmape if I see
pattern P ...
and I've gotten to the P. Have I seen an empty forall, and this is the
beginning of context, or have I seen an empty patsyn_context, and this is the
beginning of constr_stuff. I think this'll be a reduce/reduce error.
I think it may be helped by
patsyn_contxt :: forall | forall context '='
c.f the defn of 'constr'.
IN haste
Simoin
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr.
| ERDI Gergo
| Sent: 24 June 2014 13:12
| To: GHC Devs
| Subject: Help needed: parsing pattern synonym contexts
|
| Hi,
|
| I'm working on adding type signatures to pattern synonyms. The syntax
| I'm after would look something like, e.g.:
|
| pattern (Eq b) = P Int (Bool, b) (f [a]) :: (Show a) = Maybe [a]
|
| My problem is with parsing the two contexts. I wrote the parser in the
| following way, which I felt natural (actions omitted for brevity)
|
| pattern_synonym_sig :: { LSig RdrName }
| : 'pattern' patsyn_context patsyn_stuff '::' patsyn_context
| type
|
| patsyn_stuff :: { Located (Located RdrName, HsPatSynDetails (LHsType
| RdrName)) }
| : constr_stuff
|
| patsyn_context :: { LHsContext RdrName }
| : {- empty -}
| | forall context '='
|
| However, this doesn't work, no matter if those contexts are present or
| not. If I remove both contexts from the rules, i.e. if I replace
| pattern_synonym_sig with
|
| : 'pattern' patsyn_stuff '::' type
|
| then parsing succeeds when there are no contexts on either side. I've
| also tried
|
| : 'pattern' patsyn_stuff '::' ctype
|
| with the intention of recovering the required context from the ctype
| (and I could do similar tricks to get the provided context from the
| patsyn_stuff by using a modified version of constr_stuff); however, even
| that doesn't work as I expected it, i.e. with this latter version, this:
|
| pattern Single a :: (Eq a) = [a]
|
| fails with a parse error on ::.
|
| Can someone help me out here please?
|
| Thanks,
| Gergo
| ___
| 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: Associated type instances
Yes I should have said that originally. My proposed change has no loss of expressiveness; at worst you need a helper type family Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Richard Eisenberg Sent: 24 June 2014 15:26 To: Simon Peyton Jones Cc: GHC List; Manuel Chakravarty; ghc-devs@haskell.org Subject: Re: Associated type instances I'm sure I've used the feature that you're proposing to remove, but I'll adapt. To be clear, the change means no loss of expressiveness, just that I'll sometimes have to use a helper type family (closed or open), right? If I'm right there, then no complaints from me. Richard On Jun 24, 2014, at 4:07 AM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: I'm not sure when this feature was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting! But I'm just checking that no one has meanwhile become addicted to it. Simon From: Manuel Chakravarty [mailto:mchakrava...@me.comhttp://me.com] Sent: 24 June 2014 08:54 To: Simon Peyton Jones Cc: GHC List; ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Subject: Re: Associated type instances Simon, I'm not sure when this feature was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com: Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x - b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x - Int type T [x] Bool = Bool - x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b - Int type T [Bool] b = Bool - b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x - x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x - x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The shared arguments of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is shared; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration ___ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.orgmailto:glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC silently turns off dynamic output, should this be an error?
On Mon, Jun 23, 2014 at 12:58:16PM -0500, Christopher Rodrigues wrote: Additionally, is it ever valid to have a pair of .hi and .dyn_hi files with different interface hashes? You can, for example, compile package foo the vanilla way with -O, and the dynamic way without -O. You'll then get mismatched hashes. If you then try to compile bar (which depends on foo) with -dynamic-too then the idea was that it would transparently fall back to compiling the two ways separately. Otherwise every build system (Cabal, make rules, etc) that wants to use -dynamic-too would have to handle this failure and either fail or fall back itself. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Phabricator for patches and code review
Austin, replying by email is good, and your responses are helpful. But modifying the wiki page so that the next Richard will not even have to ask the questions is 10x better! Maybe you can just cut/paste text into it Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin | Seipp | Sent: 24 June 2014 18:13 | To: Richard Eisenberg | Cc: ghc-devs@haskell.org | Subject: Re: Phabricator for patches and code review | | Richard, | | Thanks, these are all actually really excellent questions. | | 1) I'm just setting things up on my machine. It says to `arc install- | certificate` in my GHC directory. Is it important precisely which clone | of GHC my directory is set up against? For example, my pull origin is | git://git.haskell.org/ghc.git and my push origin is | ssh://g...@git.haskell.org/ghc.git. Is this the right set-up? If this bit | matters, could you add it to the page? Or, if not, could you comment on | what `arc` is pulling from the ghc directory? | | The way 'arc install-certificate' knows what URL to use is based on a | file in the GHC repository, called .arcconfig - this tells arcanist | where the Phabricator instance is, and what the project callsign is. | GHC's copy is here: https://github.com/ghc/ghc/blob/master/.arcconfig | | So all you need to do is run 'install-certificate' inside the main GHC | repo, and you're done! If you've got a copy of HEAD from the past two | weeks or so, you should be golden. Once install-certificate is done, | it will write the certificate into a file called ~/.arcrc, so you | don't have to install it again. | | 2) I'm confused about what, precisely, `arc diff` does. You describe | that it updates the review available online. Does that reference some git | commits? Do I need to push by `wip` branch before `arc diff`ing? Do I | *never* need to push my branch, because `arc diff` pushes it for me? Do I | *never* need to push my branch, because Phab uses other ways of moving | the code around? For better or worse, I tend to keep my branches local | until I'm ready to merge with master, and I want to know if this needs to | change. | | You _never_ have to push a branch upstream if you don't want to (but | if you'd like to keep your changes in a safe place until you merge | them, feel free to put them on a wip/* branch!) | | What 'arc diff' does is this: when you run it, it calculates which | commits you have made. It does this by comparing your current git | repository to that of the *upstream* repository, the GHC repo. When it | calculates the set of commits, 'arc diff' then sends them all for | review. When you make a new commit, and say 'arc diff' again, it | updates it. | | 3) You say A change cannot be merged until at least one reviewer has | signed off. Does this mean merged with ghc-7.8 (or whatever the | current stable branch is)? Or does it mean merged with master? The | former is the status quo, but with a new route, so to speak. The latter | is something new, as several of us push directly to `master` without a | review. I'm not against such a change, per se, just trying to understand | it. | | Not quite. All changes go into master first, after it has been | reviewed. Afterwords, they may be picked onto the stable branch by me | or Herbert. | | My only statement is that we cannot merge a patch from Phab to master | until at least one person has given it the OK. If you put a review on | Phabricator, I believe you should at least wait for one person to | review it. That is, after all, what Phabricator is for! :) | | But note: you are *never* required to use Phabricator for your | changes! If your workflow is good for you, I don't want to interrupt | it. Instead, I want you to submit reviews so other people can read and | understand your work - existing committers *are not* forced to do | this. For example Richard, you obviously keep in close touch with | Simon, so he's likely aware of your changes and their needs. There's | no reason for you to ask SPJ for a review on a change you already have | a handle on - just go ahead and push it! | | 4) Is it now compulsory to use Phab when contributing? This page makes | it sound that way. Again, no complaints -- just trying to understand it. | | Nope! It might be so later (for external contributors without commit | access), but I first need to document all the workflows so | contributors can get a handle on it. So thanks for being the guinea | pig :) But it won't ever be compulsory for all committers. | | Again, I want people to use Phab so they can have others read, | understand, and comment about their work. There's no hard-line rule on | if you should or should not submit a review - I will totally trust | your judgement as to what you think is your best workflow. | | 5) The page says to add `austin` as a reviewer. I would expect | `thoughtpolice`. What's up with Phab usernames? Do other people I know | and love have Phab usernames distinct
Re: GHC silently turns off dynamic output, should this be an error?
On Jun 24, 2014 1:36 PM, Ian Lynagh ig...@earth.li wrote: On Mon, Jun 23, 2014 at 12:58:16PM -0500, Christopher Rodrigues wrote: Additionally, is it ever valid to have a pair of .hi and .dyn_hi files with different interface hashes? You can, for example, compile package foo the vanilla way with -O, and the dynamic way without -O. You'll then get mismatched hashes. Also, any file that uses Template Haskell could potentially generate different code at each compilation. But IMHO this isn't something ghc should try to support. John L. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pruning GADT case alternatives with uninhabitable coercion parameters
I'm glad for the interest and help. I can make an initial go of it. My current simple plan is to traverse expressions, collecting type equalities from bound coercion variables as I descend, combining them progressively with successive type unifications. The traversal is thus parametrized by a TvSubst and yields a Maybe TvSubst. The coercion variables will come from lambdas, let bindings and case alternatives. If an added equality is not unifiable given the current TvSubst, we've reached a contradiction. If the contradiction arises for one of the variables in a case alternative, then remove that alternative. How does this strategy sound? Some issues: * Nominal vs representational type equalities. * Will I want to normalize the types (with normaliseType) before unifying? * How can I unify while carrying along a type substitution environment? The Unify module exports tcUnifyTy, which takes no such environment, but not unify, which does. -- Conal On Tue, Jun 24, 2014 at 4:43 AM, Simon Peyton Jones simo...@microsoft.com wrote: we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can’t assess very well yet if this is a real problem though That is a very good point. Nevertheless, given · the typechecked HsSyn (i.e. still in source form, but with type inference fully completed · the independent contradiction-detector described below (which is independent of whether the contradiction problems it is given come from HsSyn or Core) it would be easy to give source-localised error messages Simon *From:* Dimitrios Vytiniotis *Sent:* 24 June 2014 11:58 *To:* Simon Peyton Jones; Conal Elliott; ghc-devs@haskell.org *Cc:* Nikolaos S. Papaspyrou (nic...@softlab.ntua.gr); George Karachalias *Subject:* RE: Pruning GADT case alternatives with uninhabitable coercion parameters Yes it would be better in the sense that we don’t really want to be dealing with unification variables and evidence when we simply use the constraint solver to detect inconsistencies in possibly missing patterns, but the concern has been that if we are already desugared and in core maybe we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can’t assess very well yet if this is a real problem though … In general I agree that a simple constraint solver for Core might be an independently useful tool for this kind of optimization. (I think George had thought about this too). Thanks! d- *From:* Simon Peyton Jones *Sent:* Tuesday, June 24, 2014 11:41 AM *To:* Conal Elliott; ghc-devs@haskell.org *Cc:* Dimitrios Vytiniotis; Nikolaos S. Papaspyrou (nic...@softlab.ntua.gr); George Karachalias; Simon Peyton Jones *Subject:* RE: Pruning GADT case alternatives with uninhabitable coercion parameters Conal This also relates to detecting redundant or overlapped patterns in source programs. I know that Dimitrios is looking at this with Tom, Nikolas, George who I’m cc’ing him. I think their current approach may be to integrate the overlap checking with the constraint solver in the type checker. But that isn’t going to work for optimising Core. An alternative approach would be to implement a specialised constraint solver. It could be MUCH simpler than the one in the inference engine, because (a) there are no unification variables to worry about, (b) there is no need to gather evidence. More or less it’s task could be to answer the question IsC |- Ddefinitely a contradiction? where C are the “given” constraints (from enclosing pattern matches) and D are the “wanted” constraints (from the current pattern match that may be unreachable). I don’t think it would be hard to implement such a function. I’d be happy to help advise if someone wants to take it on. Dimitrios: If we had such a function, then maybe it’d be better to use it for the pattern-matching overlap detection too? Simon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org ghc-devs-boun...@haskell.org] *On Behalf Of *Conal Elliott *Sent:* 20 June 2014 18:59 *To:* ghc-devs@haskell.org *Subject:* Pruning GADT case alternatives with uninhabitable coercion parameters I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: case ds of wild (Sum Int) L (~# :: S (S Z) ~N Z) a1 - f a1 B n1 (~# :: S (S Z) ~N S n1) uv - ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up:
Re: Pruning GADT case alternatives with uninhabitable coercion parameters
My first go is at https://github.com/conal/hermit-extras/blob/master/src/HERMIT/Extras.hs#L1030 . It type-checks. I haven't tried running it yet. Comments most welcome! -- Conal On Tue, Jun 24, 2014 at 4:10 PM, Conal Elliott co...@conal.net wrote: I'm glad for the interest and help. I can make an initial go of it. My current simple plan is to traverse expressions, collecting type equalities from bound coercion variables as I descend, combining them progressively with successive type unifications. The traversal is thus parametrized by a TvSubst and yields a Maybe TvSubst. The coercion variables will come from lambdas, let bindings and case alternatives. If an added equality is not unifiable given the current TvSubst, we've reached a contradiction. If the contradiction arises for one of the variables in a case alternative, then remove that alternative. How does this strategy sound? Some issues: * Nominal vs representational type equalities. * Will I want to normalize the types (with normaliseType) before unifying? * How can I unify while carrying along a type substitution environment? The Unify module exports tcUnifyTy, which takes no such environment, but not unify, which does. -- Conal On Tue, Jun 24, 2014 at 4:43 AM, Simon Peyton Jones simo...@microsoft.com wrote: we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can’t assess very well yet if this is a real problem though That is a very good point. Nevertheless, given · the typechecked HsSyn (i.e. still in source form, but with type inference fully completed · the independent contradiction-detector described below (which is independent of whether the contradiction problems it is given come from HsSyn or Core) it would be easy to give source-localised error messages Simon *From:* Dimitrios Vytiniotis *Sent:* 24 June 2014 11:58 *To:* Simon Peyton Jones; Conal Elliott; ghc-devs@haskell.org *Cc:* Nikolaos S. Papaspyrou (nic...@softlab.ntua.gr); George Karachalias *Subject:* RE: Pruning GADT case alternatives with uninhabitable coercion parameters Yes it would be better in the sense that we don’t really want to be dealing with unification variables and evidence when we simply use the constraint solver to detect inconsistencies in possibly missing patterns, but the concern has been that if we are already desugared and in core maybe we need to do a bit more work to re-connect to source pattern locations and nested patterns? I can’t assess very well yet if this is a real problem though … In general I agree that a simple constraint solver for Core might be an independently useful tool for this kind of optimization. (I think George had thought about this too). Thanks! d- *From:* Simon Peyton Jones *Sent:* Tuesday, June 24, 2014 11:41 AM *To:* Conal Elliott; ghc-devs@haskell.org *Cc:* Dimitrios Vytiniotis; Nikolaos S. Papaspyrou ( nic...@softlab.ntua.gr); George Karachalias; Simon Peyton Jones *Subject:* RE: Pruning GADT case alternatives with uninhabitable coercion parameters Conal This also relates to detecting redundant or overlapped patterns in source programs. I know that Dimitrios is looking at this with Tom, Nikolas, George who I’m cc’ing him. I think their current approach may be to integrate the overlap checking with the constraint solver in the type checker. But that isn’t going to work for optimising Core. An alternative approach would be to implement a specialised constraint solver. It could be MUCH simpler than the one in the inference engine, because (a) there are no unification variables to worry about, (b) there is no need to gather evidence. More or less it’s task could be to answer the question IsC |- Ddefinitely a contradiction? where C are the “given” constraints (from enclosing pattern matches) and D are the “wanted” constraints (from the current pattern match that may be unreachable). I don’t think it would be hard to implement such a function. I’d be happy to help advise if someone wants to take it on. Dimitrios: If we had such a function, then maybe it’d be better to use it for the pattern-matching overlap detection too? Simon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org ghc-devs-boun...@haskell.org] *On Behalf Of *Conal Elliott *Sent:* 20 June 2014 18:59 *To:* ghc-devs@haskell.org *Subject:* Pruning GADT case alternatives with uninhabitable coercion parameters I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: case ds of wild (Sum Int) L (~# :: S (S Z) ~N Z) a1 - f a1 B n1 (~# :: S (S Z) ~N S n1) uv - ... Note the kind
Re: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85)
On 06/24/2014 07:47 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/d8abf85f8ca176854e9d5d0b12371c4bc402aac3/ghc --- commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 Author: Johan Tibell johan.tib...@gmail.com Date: Mon Jun 9 11:43:21 2014 +0200 Add more primops for atomic ops on byte arrays Summary: Add more primops for atomic ops on byte arrays Adds the following primops: * atomicReadIntArray# * atomicWriteIntArray# * fetchSubIntArray# * fetchOrIntArray# * fetchXorIntArray# * fetchAndIntArray# Makes these pre-existing out-of-line primops inline: * fetchAddIntArray# * casIntArray# --- d8abf85f8ca176854e9d5d0b12371c4bc402aac3 compiler/cmm/CmmMachOp.hs | 19 ++ compiler/cmm/CmmSink.hs| 4 + compiler/cmm/PprC.hs | 4 + compiler/codeGen/StgCmmPrim.hs | 94 +++ compiler/llvmGen/Llvm/AbsSyn.hs| 7 + compiler/llvmGen/Llvm/PpLlvm.hs| 18 +- compiler/llvmGen/LlvmCodeGen/CodeGen.hs| 71 -- compiler/nativeGen/CPrim.hs| 50 +++- compiler/nativeGen/PPC/CodeGen.hs | 4 + compiler/nativeGen/SPARC/CodeGen.hs| 4 + compiler/nativeGen/X86/CodeGen.hs | 92 +++ compiler/nativeGen/X86/Instr.hs| 38 ++- compiler/nativeGen/X86/Ppr.hs | 8 + compiler/prelude/primops.txt.pp| 76 +- includes/stg/MiscClosures.h| 1 - libraries/ghc-prim/cbits/atomic.c | 280 + libraries/ghc-prim/ghc-prim.cabal | 1 + rts/Linker.c | 1 - rts/PrimOps.cmm| 12 - testsuite/tests/concurrent/should_run/.gitignore | 1 + .../tests/concurrent/should_run/AtomicPrimops.hs | 245 ++ .../concurrent/should_run/AtomicPrimops.stdout | 7 + testsuite/tests/concurrent/should_run/all.T| 1 + 23 files changed, 984 insertions(+), 54 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 d8abf85f8ca176854e9d5d0b12371c4bc402aac3 ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits I think the above killed compilation on 32-bit boxes. See the usually-green boxes turn red at [1], specifically validator1-linux-x86-head, freebsd-i386-head and solaris-x86-head. The error looks like: inplace/bin/ghc-stage1 -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140624 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1Q6 assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 It'd be great if the devs would look at [1] every day or so. [1]: http://haskell.inf.elte.hu/builders/ -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85)
I don't understand the error (are we out of registers in the register allocator? what can we do about that?). Simon could you please explain. As for the continuos builds, can't we have them email the list upon breakages? On Wed, Jun 25, 2014 at 7:26 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 06/24/2014 07:47 PM, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/d8abf85f8ca176854e9d5d0b12371c4bc402aac3/ghc --- commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 Author: Johan Tibell johan.tib...@gmail.com Date: Mon Jun 9 11:43:21 2014 +0200 Add more primops for atomic ops on byte arrays Summary: Add more primops for atomic ops on byte arrays Adds the following primops: * atomicReadIntArray# * atomicWriteIntArray# * fetchSubIntArray# * fetchOrIntArray# * fetchXorIntArray# * fetchAndIntArray# Makes these pre-existing out-of-line primops inline: * fetchAddIntArray# * casIntArray# --- d8abf85f8ca176854e9d5d0b12371c4bc402aac3 compiler/cmm/CmmMachOp.hs | 19 ++ compiler/cmm/CmmSink.hs| 4 + compiler/cmm/PprC.hs | 4 + compiler/codeGen/StgCmmPrim.hs | 94 +++ compiler/llvmGen/Llvm/AbsSyn.hs| 7 + compiler/llvmGen/Llvm/PpLlvm.hs| 18 +- compiler/llvmGen/LlvmCodeGen/CodeGen.hs| 71 -- compiler/nativeGen/CPrim.hs| 50 +++- compiler/nativeGen/PPC/CodeGen.hs | 4 + compiler/nativeGen/SPARC/CodeGen.hs| 4 + compiler/nativeGen/X86/CodeGen.hs | 92 +++ compiler/nativeGen/X86/Instr.hs| 38 ++- compiler/nativeGen/X86/Ppr.hs | 8 + compiler/prelude/primops.txt.pp| 76 +- includes/stg/MiscClosures.h| 1 - libraries/ghc-prim/cbits/atomic.c | 280 + libraries/ghc-prim/ghc-prim.cabal | 1 + rts/Linker.c | 1 - rts/PrimOps.cmm| 12 - testsuite/tests/concurrent/should_run/.gitignore | 1 + .../tests/concurrent/should_run/AtomicPrimops.hs | 245 ++ .../concurrent/should_run/AtomicPrimops.stdout | 7 + testsuite/tests/concurrent/should_run/all.T| 1 + 23 files changed, 984 insertions(+), 54 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 d8abf85f8ca176854e9d5d0b12371c4bc402aac3 ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits I think the above killed compilation on 32-bit boxes. See the usually-green boxes turn red at [1], specifically validator1-linux-x86-head, freebsd-i386-head and solaris-x86-head. The error looks like: inplace/bin/ghc-stage1 -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140624 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1Q6 assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 It'd be great if the devs would look at [1] every day or so. [1]: http://haskell.inf.elte.hu/builders/
Re: [commit: ghc] master: Add more primops for atomic ops on byte arrays (d8abf85)
On 06/25/2014 07:37 AM, Johan Tibell wrote: I don't understand the error (are we out of registers in the register allocator? what can we do about that?). Simon could you please explain. As for the continuos builds, can't we have them email the list upon breakages? We could but I think there is no mechanism to tell what's meaningful breakage and how to present it. I think this should be part of the discussion in the “Offering GHC builder build slaves” thread and someone just needs to sit down and hook it up. This includes fancier things such as blaming commit ranges for specific test changes c. Short-term solution would be to subscribe to ghc-bui...@haskell.org and filter out the contents so only failing builds are shown, taking care to exclude the slaves which are failing constantly due to unrelated reasons. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
