darcs

Issue 115 match patches touching given files.

Title match patches touching given files.
Priority feature Status resolved
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, kowey, thorkilnaur, tommy, zooko
Assigned To
Topics ProbablyEasy

Created on 2006-01-26.06:19:12 by zooko, last changed 2009-08-27.14:17:57 by admin.

Files
File name Uploaded Type Edit Remove
match_patchy.dpatch dmitry.kurochkin, 2008-08-21.10:37:52 text/x-darcs-patch
Messages
msg424 (view) Author: zooko Date: 2006-01-26.06:19:09
That is, I wish to select all files that touched any files whose names match the regex.
msg425 (view) Author: tommy Date: 2006-01-26.12:14:17
On Thu, Jan 26, 2006 at 06:19:13AM +0000, Zooko wrote:
> That is, I wish to select all [patches] that touched any files whose names match the regex.

It should also work on directories.  How about the more general
name 'touching' (I think it has been suggested before), like:

  'darcs pull --matches='touching some/thing/'
msg426 (view) Author: droundy Date: 2006-01-26.13:54:30
On Thu, Jan 26, 2006 at 12:14:18PM +0000, Tommy Pettersson wrote:
> It should also work on directories.  How about the more general
> name 'touching' (I think it has been suggested before), like:
> 
>   'darcs pull --matches='touching some/thing/'

Sounds good to me.  Shouldn't be too hard, except that someone would have
to deal with my (not terribly clear) match-parsing code.
-- 
David Roundy
http://www.darcs.net
msg5618 (view) Author: dmitry.kurochkin Date: 2008-08-20.21:39:17
Hello.

Note: I have little experience with haskell and no experience with darcs
internals, so I do not guarantee anything below makes sense :)

I wanted to try working on something in darcs except for HTTP download. And
decided to try implementing this feature. But I have encountered some problems
with types and hope you can show me the way to go.

As I understand new match expression is as simple as adding new function in
Darcs.Patch.Match module of type:

String -> MatchFun p

which is actually:

String -> Sealed2 (PatchInfoAnd p) -> Bool

To lookup files touched by a patch list_touched_files from Darcs.Patch.Patchy
can be used. But to use this function p should be instance of Commute. So I
started adding contexts (Commute p) everywhere. And got to a problem with
helpOnMatchers function. GHC says that type p is ambiguous. Here is a small
program to demonstrate the issue:

{-# OPTIONS_GHC -fglasgow-exts #-}
module Main where

import System.IO ( putStrLn )

f :: Show a => [a]
f = []

main :: IO ()
main = if null f
       then putStrLn "1"
       else putStrLn "2"

GHC fails to compile with error:

    Ambiguous type variable `a' in the constraint:
      `Show a' arising from a use of `f' at /home/dikk/tmp/test.hs:10:15
    Probable fix: add a type signature that fixes these type variable(s)

If I remove (Show a) context it compiles fine. I do not understand why context
changes everything. Is it a bug or I am missing something?

Then I tried to use existential types for MatchFun and Matcher. But got another
problem with functions like make_matcher: p type inside Matcher is not the same
as p type in function parameter...

Can someone please enlighten me how to work around the problems? And if what I
do is actually the right way to go.

Regards,
  Dmitry
msg5619 (view) Author: dagit Date: 2008-08-20.21:56:14
On Wed, Aug 20, 2008 at 2:39 PM, dmitry.kurochkin <bugs@darcs.net> wrote:
>
> dmitry.kurochkin <dmitry.kurochkin@gmail.com> added the comment:
>
> Hello.
>
> Note: I have little experience with haskell and no experience with darcs
> internals, so I do not guarantee anything below makes sense :)

You're making perfect sense :)

> I wanted to try working on something in darcs except for HTTP download. And
> decided to try implementing this feature. But I have encountered some problems
> with types and hope you can show me the way to go.
>
> As I understand new match expression is as simple as adding new function in
> Darcs.Patch.Match module of type:
>
> String -> MatchFun p
>
> which is actually:
>
> String -> Sealed2 (PatchInfoAnd p) -> Bool

It's sort of unfortunate that we have to involve the Sealed2 type
here.  Thankfully, I don't think that's a problem in your example.

> To lookup files touched by a patch list_touched_files from Darcs.Patch.Patchy
> can be used. But to use this function p should be instance of Commute. So I
> started adding contexts (Commute p) everywhere. And got to a problem with
> helpOnMatchers function. GHC says that type p is ambiguous. Here is a small
> program to demonstrate the issue:
>
> {-# OPTIONS_GHC -fglasgow-exts #-}
> module Main where
>
> import System.IO ( putStrLn )
>
> f :: Show a => [a]
> f = []
>
> main :: IO ()
> main = if null f
>       then putStrLn "1"
>       else putStrLn "2"
>
> GHC fails to compile with error:
>
>    Ambiguous type variable `a' in the constraint:
>      `Show a' arising from a use of `f' at /home/dikk/tmp/test.hs:10:15
>    Probable fix: add a type signature that fixes these type variable(s)
>
> If I remove (Show a) context it compiles fine. I do not understand why context
> changes everything. Is it a bug or I am missing something?

GHC complains here because it doesn't know which type to use.  In the
Show example, many types have instances of Show.  But which one did
you mean?  GHC wants to be able to infer which one you meant when the
function is called as this allows it to pass the correct dictionary at
run-time.  GHC implements type classes by implicitly passing
dictionaries where the keys are types and the values are the instance
definitions.  In the above example it doesn't matter what dictionary
is passed because no key-lookup would need to be done.  Perhaps, all
such programs are rejected because that is the simplest way to keep
programs type safe.  Yes it does seem like a bit of a bug though and
people would just argue that it's simpler for the programmer to remove
the unused contexts.

> Then I tried to use existential types for MatchFun and Matcher. But got another
> problem with functions like make_matcher: p type inside Matcher is not the same
> as p type in function parameter...

Ah yes.  What was the existential type you tried?  Untested, maybe it
may need to be:
String -> (forall p. Patchy p => Sealed2 (PatchInfoAnd p)) -> Bool

But, as I'm sure you would soon find out, existential types and 'type
Foo = ...' do not play well together.  Thus, you'd be best off
scraping the type alias and hard wiring it in.

The way to make the two types of p match up is to use lexically scoped
type variables.  Add:
{-# OPTIONS_GHC -fglasgow-ext #-}

to the top of the first code block in the file, then you activate
lexically scoped type variables by being explicit about the foralls.
Of course, this still wouldn't work with the type I gave above because
the existential p in MatchFun would always be different than one in an
explicit forall.

> Can someone please enlighten me how to work around the problems? And if what I
> do is actually the right way to go.

It would be most helpful if you could send some of your previous
attempts and we could debug them.

Jason
msg5622 (view) Author: dmitry.kurochkin Date: 2008-08-21.10:37:52
Hi Jason.

Thanks for quick reply! Attached is my attempt to make Matcher existential type.
It does not compile. And I do not know how to fix it :)

I used the following type for matching functions:

(forall p . Patchy p => Sealed2 (PatchInfoAnd p) -> Bool)

As you suggested I removed MatchFun type alias.

Hope you can give me some insights on how to solve this.

Thanks,
  Dmitry
Attachments
msg5623 (view) Author: droundy Date: 2008-08-21.12:15:07
Hi Dmitry,

I think the best solution would be to avoid the use of existentials altogether
for this problem, so you'd have

data Matcher p = MATCH String (Sealed2 (PatchInfoAnd p) -> Bool)

Then you'd have to add contexts everywhere (as you tried at first).  And then
you'd have to add type signatures in some places.  Since there are bits of code
that don't actually use the matcher (and thus don't care what the type p is),
you can just add a signature telling them to just use RealPatch (or Patch, it
doesn't matter).

David
msg5626 (view) Author: dmitry.kurochkin Date: 2008-08-21.18:45:08
Thanks David! It really works! I will send the patch after tests complete.

I still wonder if it is possible to implement this with exsistentials...

Regards,
  Dmitry
msg5628 (view) Author: dmitry.kurochkin Date: 2008-08-21.23:07:49
The following patch updated the status of issue115 to be resolved:

* Resolve issue115: match patches touching given files.
History
Date User Action Args
2006-01-26 06:19:12zookocreate
2006-01-26 12:14:18tommysetstatus: unread -> unknown
nosy: droundy, tommy, zooko
messages: + msg425
2006-01-26 13:54:32droundysetnosy: droundy, tommy, zooko
messages: + msg426
2006-01-31 13:19:45droundysetnosy: droundy, tommy, zooko
2006-08-06 22:14:21koweysettopic: + ProbablyEasy
nosy: droundy, tommy, zooko
2008-02-07 05:08:34markstossetstatus: unknown -> deferred
nosy: + kowey, beschmi
title: I wish for darcs pull --match="files foo|bar|splotz.*(c|h)" -> wish: darcs pull --match="touching foo|bar|splotz.*(c|h)"
2008-05-07 16:09:13koweysetstatus: deferred -> unknown
nosy: + dagit
2008-05-22 09:18:11koweysetpriority: wishlist -> feature
nosy: droundy, tommy, beschmi, kowey, zooko, dagit
2008-08-20 21:39:22dmitry.kurochkinsetnosy: + dmitry.kurochkin
messages: + msg5618
2008-08-20 21:56:17dagitsetnosy: droundy, tommy, beschmi, kowey, zooko, dagit, dmitry.kurochkin
messages: + msg5619
2008-08-21 10:37:55dmitry.kurochkinsetfiles: + match_patchy.dpatch
nosy: droundy, tommy, beschmi, kowey, zooko, dagit, dmitry.kurochkin
messages: + msg5622
2008-08-21 12:15:09droundysetnosy: droundy, tommy, beschmi, kowey, zooko, dagit, dmitry.kurochkin
messages: + msg5623
2008-08-21 18:45:10dmitry.kurochkinsetnosy: droundy, tommy, beschmi, kowey, zooko, dagit, dmitry.kurochkin
messages: + msg5626
2008-08-21 23:07:51dmitry.kurochkinsetstatus: unknown -> resolved-in-unstable
nosy: droundy, tommy, beschmi, kowey, zooko, dagit, dmitry.kurochkin
messages: + msg5628
title: wish: darcs pull --match="touching foo|bar|splotz.*(c|h)" -> match patches touching given files.
2009-04-22 03:27:46twbsetstatus: resolved-in-unstable -> resolved
nosy: + simon, thorkilnaur
2009-08-06 17:46:06adminsetnosy: + markstos, jast, Serware, darcs-devel, mornfall, - droundy
2009-08-06 20:48:28adminsetnosy: - beschmi
2009-08-10 21:43:14adminsetnosy: - markstos, darcs-devel, jast, Serware, mornfall
2009-08-10 23:48:56adminsetnosy: - dagit
2009-08-25 17:43:59adminsetnosy: + darcs-devel, - simon
2009-08-27 14:17:57adminsetnosy: tommy, kowey, darcs-devel, zooko, thorkilnaur, dmitry.kurochkin