That is, I wish to select all files that touched any files whose names match the regex.

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/'

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

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

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

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

• match_patchy.dpatch

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

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

The following patch updated the status of issue115 to be resolved:

* Resolve issue115: match patches touching given files.