Re: Uniquable RdrName instance
FYI it's #7828, not #7282. Of course, yes. would making arrow remindable involve dropping the arr == haksell functions assumption or doing something that would allow generalized arrows? Not sure if I fully understand what you mean. There's an idea to give up on current desugaring that heavily uses arr, etc. in favor of desugaring based on bind equivalents for arrows. Is this what you wanted to know? There's some discussion on the Trac you might want to follow. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Phabricator for patches and code review
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 go to the Herald tool you have yourself automatically subscribed to diffs that touch areas of the code that you're interested in. Pro tip: the keyboard shortcuts are really useful, especially z. Hit ? to see all the shortcuts. Cheers, Simon Janek Dnia niedziela, 8 czerwca 2014, Simon Marlow napisał: On 07/06/2014 07:21, Manuel M T Chakravarty wrote: So, why not put everything on GutHub and use pull requests and so on? github just isn't great for doing code reviews. No side-by-side diffs, and it sends you a separate email for every single comment, there's no concept of a review consisting of multiple inline comments (unless I've missed something). I'm afraid if we were using this for regular reviews I would have to disable the email notifications, which makes it significantly less useful. SimonM writes that Phabricator is better than GitHub. I’m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. Well, you've tipped the balance with somewhat and significant here, I'd say Phabricator is significantly better than github for code reviews, while installing arc is somewhat annoying :-) I have to admit it's not a no-brainer, but I do worry that github just wouldn't cut it for doing a lot of code reviewing, whereas I spend my life inside Phabricator so I know it works really well. What's more, github doesn't let you put animated gifs in code reviews. Need I say more? Cheers, Simon We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let’s outsource the effort to GitHub. Manuel Simon Peyton Jones simo...@microsoft.com: At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Austin Seipp | Sent: 06 June 2014 05:06 | To: ghc-devs@haskell.org | Subject: RFC: Phabricator for patches and code review | | Hello all, | | Recently, while doing server maintenance, several of the | administrators for Haskell.org set up an instance of Phabricator[1], | located at https://phabricator.haskell.org | | For those who aren't aware, Phabricator (or Phab) is a suite of | tools for software development. Think of it like a polished, | semi-private GitHub with a lot of applications and tools for all kinds | of needs. We've been using it to do issue tracking for Haskell.org | maintenance and like it a lot so far. | | One very nice aspect of Phabricator though is it has a very nice code | review tool, called 'Differential', that is very useful. For people | who have used a tool like Review Board, it's similar.
Re: Uniquable RdrName instance
So, without really trying to understand the code, what you are saying is this: you want a finite map from RdrNames. That seems sensible enough, if the domain elements all appear in the same scope in the Haskell source. I don't have enough perspective to say whether a Uniquable instance is the way to get to a finite map here. Richard On Jun 16, 2014, at 3:33 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Why do you want this? The danger I see lurking is that you might find two RdrNames that give the same answer to getUnique but represent different Yes, that's exactly my concern. Why do you want this? I'm working on #7282 - RebindableSyntax and Arrows. Here's a snippet from desugaring of arrow notation: leaves = concatMap leavesMatch matches where leavesMatch :: LMatch Id (Located (body Id)) - [(Located (body Id), IdSet)] leavesMatch (L _ (Match pats _ (GRHSs grhss binds))) = let defined_vars = mkVarSet (collectPatsBinders pats) `unionVarSet` mkVarSet (collectLocalBinders binds) in [(body, mkVarSet (collectLStmtsBinders stmts) `unionVarSet` defined_vars) | L _ (GRHS stmts body) - grhss] This is in the desugarer. But I need to also know `length leaves` at the renaming stage, which means I need to call `concatMap leavesMatch matches`. The problem is that in the renamer my datatypes are not parametrised by `Id`. I turned `Id` into a type parameter `id`, but then I can't use VarSets. I could use more general UniqueSets but only if `id` type parameter is an instance of Uniquable. And since in the renamer the datatypes are parametrized with RdrName this leads me to wanting Uniqable RdrName instance. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Uniquable RdrName instance
We just haven't needed one so far. Can a RdrName and a Name have the same Unique? Well, of course that just depends on what you are using the RdrName Uniques for. It's not a question that has a yes or no answer. Does it matter if (Orig m x) and (Orig n x) have the same Unique? Same answer, except that I bet the answer is yes it matters. FWIW the OrigNameCache is a finite map keyed by (ModuleName,Orig) pairs. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan | Stolarek | Sent: 16 June 2014 12:45 | To: ghc-devs@haskell.org | Subject: Uniquable RdrName instance | | Hi all, | | I just found myself in the need of Uniquable instance for RdrName. I'm | surprised that such instance does not exist already because other | datatypes like Name or OccName already have Uniquable instances. So, is | there a reason why Uniquable instance for RdrName does not exist already | (other than it wasn't needed)? How should such an instance look like? | I made an | attempt: | | rdrNameUnique :: RdrName - Unique | rdrNameUnique (Unqual occName) = getUnique occName rdrNameUnique (Qual _ | occName) = getUnique occName rdrNameUnique (Orig _ occName) = getUnique | occName | rdrNameUnique (Exact name) = getUnique name | | But I suspect this might be wrong: | - cases 1 and 4 simply return a Unique for the OccName/Name stored | inside RdrName. I think this will assign the same Unique to RdrName and | corresponding OccName/Name. Is this allowed? | - cases 2 and 3 ignore the Module stored inside RdrName. Again, this | assigns the RdrName with a Unique identical to OccNames stored inside | it. | | Help appreciated. | | Janek | ___ | 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
Deep embeddings and Arrows Re: Uniquable RdrName instance
to clarify: having bind would be equivalent to having arr for the purposes of my question (assuming its the standard monadic bind). having arr :: (b - c) - a b c is tantamount to assuming that any haskell function can be embedded in an arrow instance which prevents a lot of interesting deep embedding uses of the Arrow abstraction/ or at least makes it a bit tricker. (eg things like writing circuits or certain types of compiled FRP models). On Tue, Jun 17, 2014 at 4:06 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: FYI it's #7828, not #7282. Of course, yes. would making arrow remindable involve dropping the arr == haksell functions assumption or doing something that would allow generalized arrows? Not sure if I fully understand what you mean. There's an idea to give up on current desugaring that heavily uses arr, etc. in favor of desugaring based on bind equivalents for arrows. Is this what you wanted to know? There's some discussion on the Trac you might want to follow. Janek ___ 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: Deep embeddings and Arrows Re: Uniquable RdrName instance
yes, that what I meant, though the standard = does need to be used carefully on a restricted universe of types to ensure you can get a deep embedding On Tue, Jun 17, 2014 at 5:33 PM, John Lato jwl...@gmail.com wrote: Did you mean pure/return as the monadic equivalent? I've frequently encountered embeddings where it's possible to have a valid * and = but not pure (or fmap). On Jun 17, 2014 1:46 PM, Carter Schonwald carter.schonw...@gmail.com wrote: ok, so one example of this design, albeit implemented in a funky way (compiler passes written in coq), was Adam Megacz's Garrows project http://www.megacz.com/berkeley/garrows/ a more concrete example of a haskell lib that enjoys a deep embedding and doesn't let you inject arbitrary (f:: a- b ) would be Accelerate hackage.haskell.org/package/accelerate (the expression language there could be made into an arr free Arrow but not an Arrow that has arr) basically not having arr or the monadic equiv bind, gives you a way to write libs where you can get a program as a first order AST when you run it and be able to analyze/compile it in user land at runtime On Tue, Jun 17, 2014 at 4:37 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: assuming that any haskell function can be embedded in an arrow instance (...) prevents a lot of interesting deep embedding uses of the Arrow abstraction Could you point me to some specific examples? I'm new to arrows and definitely far from groking all the arcana of their usage. Janek ___ 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: Deep embeddings and Arrows Re: Uniquable RdrName instance
On Tue, Jun 17, 2014 at 03:10:14PM -0400, Carter Schonwald wrote: to clarify: having bind would be equivalent to having arr for the purposes of my question (assuming its the standard monadic bind). having arr :: (b - c) - a b c is tantamount to assuming that any haskell function can be embedded in an arrow instance which prevents a lot of interesting deep embedding uses of the Arrow abstraction/ or at least makes it a bit tricker. (eg things like writing circuits or certain types of compiled FRP models). I have two answers: First, it's not that difficult using the Arrow class. For example, see the netlist example at the end of my Fun of Programming slides (http://www.soi.city.ac.uk/~ross/papers/fop.html). The idea is that arr can take any function, but if you require the circuit to be parametric in the value types, you can limit the types of function the programmer can pass to arr to simple plumbing. Second, suppose we split arr :: forall b c. (b - c) - a b c into two primitives (^) :: forall b c d. (b - c) - a c d - a b d id :: forall b. a b b Arrow notation relies on (^) being a contravariant functor -- that's what allows the translation to manipulate environments, and it gives you a substitution property for commands. On the other hand it doesn't need id (or equivalently returnA). Perhaps the problem is the universally quantified b in the type of id. One might instead use a variant of id constrained to an ADT with just the operations you want. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
