This is a sort of long-term task.  We should probably first get a clearer
picture what we mean by this (how do we define victory here?)

We pass [DarcsFlag] around a lot.  This is simple to write, but hard to read
(hard to reason about anyway).

Perhaps Petr's approach (splitting DarcsFlag into subflags like Compression) is
a good start?

Also, another thing that we may need to be deal with is the notion of defaults
and overrides.  It may be nice to have a uniform architecture for declaring flag
defaults.

I just used an emacs macro to put each flag on its own line then counted the
lines in the region and emacs said 152.  So that's a lot of flags.  I'm listing
them here so people can look at the list easily, from Darcs.Flags:

Help 
ListOptions 
NoTest 
Test
HelpOnMatch 
OnlyChangesToFiles
LeaveTestDir 
NoLeaveTestDir
Timings 
Debug 
DebugVerbose 
DebugHTTP
Verbose 
NormalVerbosity 
Quiet
Target String 
Cc String
Output AbsolutePathOrStd 
OutputAutoName AbsolutePath
Subject String
SendmailCmd String 
Author String 
PatchName String
OnePatch String 
SeveralPatch String
AfterPatch String 
UpToPatch String
TagName String 
LastN Int 
PatchIndexRange Int Int
NumberPatches
OneTag String 
AfterTag String 
UpToTag String
Context AbsolutePath 
Count
LogFile AbsolutePath 
RmLogFile
DistName String 
All
Recursive 
NoRecursive 
Reorder
RestrictPaths 
DontRestrictPaths
AskDeps 
NoAskDeps 
IgnoreTimes 
LookForAdds 
NoLookForAdds
AnyOrder 
CreatorHash String
Intersection 
Union 
Complement
Sign 
SignAs String 
NoSign 
SignSSL String
HappyForwarding
Verify AbsolutePath 
VerifySSL AbsolutePath
SSHControlMaster 
NoSSHControlMaster
EditDescription 
NoEditDescription
Toks String
EditLongComment 
NoEditLongComment 
PromptLongComment
AllowConflicts 
MarkConflicts 
NoAllowConflicts
Boring 
AllowCaseOnly 
AllowWindowsReserved
DontGrabDeps 
DontPromptForDependencies 
PromptForDependencies
Compress 
NoCompress 
UnCompress
WorkDir String 
RepoDir String 
RemoteRepo String
Reply String 
ApplyAs String
MachineReadable 
HumanReadable
Pipe 
Interactive
DiffCmd String
ExternalMerge String 
Summary 
NoSummary
Unified 
Reverse
CheckPoint 
Partial 
Complete 
Lazy 
Ephemeral
FixFilePath AbsolutePath AbsolutePath 
DiffFlags String
XMLOutput
ForceReplace
OnePattern PatchMatch 
SeveralPattern PatchMatch
AfterPattern PatchMatch 
UpToPattern PatchMatch
NonApply 
NonVerify 
NonForce
DryRun 
SetDefault 
NoSetDefault
FancyMoveAdd 
NoFancyMoveAdd
Disable 
SetScriptsExecutable 
DontSetScriptsExecutable
UseHashedInventory 
UseOldFashionedInventory
UseFormat2
PristinePlain 
PristineNone 
NoUpdateWorking
Sibling AbsolutePath 
Relink 
RelinkPristine 
NoLinks
Files 
NoFiles 
Directories 
NoDirectories
Pending 
NoPending
PosthookCmd String 
NoPosthook 
AskPosthook 
RunPosthook
PrehookCmd String  
NoPrehook  
AskPrehook  
RunPrehook
UMask String
StoreInMemory
HTTPPipelining 
NoHTTPPipelining
NoCache
AllowUnrelatedRepos
NullFlag

One of the past proposals on dealing with the flags that I have heard (I think
from Mornfall) is that we should have functions like:
compression :: [DarcsFlag] -> Compression

And then figure out which functions need to take Compression in place of
[DarcsFlag].

The main thing holding us back from doing this is that we need to create new
data types for each purpose, ie. Compression, and new functions, ie.
compression, and then figure out where to pass Compression instead of [DarcsFlag].

This means it could be a really big task.  So it's probably preferable to do it
in small chunks.

This is one of those long-term tasks.  I suggest we start by splitting DarcsFlag.

We could even consider constructors like CompressionF Compression as a sort of
transition phase.

As we start doing this, I think we'll get a clearer picture how this should
interact with Darcs.Argument and the rest of darcs

See potentially related issues:

- issue1158: mutually exclusive --match --patch
- issue1534: mutually exclusive --context --match
- issue1437: replace --no-foo with --foo=no?
- issue1550: farm out command line processing to 3rd party (eg. CmdArgs)

I claim that Petr is starting work on this with his bottom-up approach

As of now, the reviewed branch is such that the Darcs.Repository.* and 
the Darcs.Patch.* modules no longer use DarcsFlag nor depend on the 
module Darcs.UI.Flags (which was Darcs.Flags before the refactor I did).

I introduced the module Darcs.Repository.Flags to represent the 
repository function arguments, and the UI part of the code takes care of 
converting the [DarcsFlag] list from the commandline to 
Darcs.Repository.Flags flags (as suggested by 
http://bugs.darcs.net/msg6395 ).

I think it's safe to close this issue since there exist other and more 
specific flag-related ones.