[darcs-devel] [patch1179] Darcs.Repository.Flags: added Eq instanc... (and 4 more)

Ganesh Sittampalam ganesh at earth.li
Sat Nov 8 19:47:53 UTC 2014


Hi Ben,

On 08/11/2014 18:56, Ben Franksen wrote:

> Ganesh Sittampalam wrote:

>> The negatives are that it's a bit more complicated than the old system
>> and the type signatures for the sets of options in each command are
>> pretty verbose.
> 
> Yes, they are horrible, and it is part of why I had some reservations about 
> the whole idea. They make me feel like programming in one of these first 
> order statically typed languages (C, Java, Pascal). A proper record system 
> for Haskell (with row polymorphism) would make this a lot nicer...

I'm playing around with moving them inline to the DarcsCommand
specifications and avoiding the boilerplate odesc/defaultFlags/ocheck.
If it works out, it'll mean they can be just specified once there and
avoid needing to give a signature anywhere.

> I remember that getting *all* tests to succeed again was a major headache -- 
> the last few took me a few days and some restructuring. The problem is that 
> the new way to define options requires you to think about when and how 
> options interact with each other. I think this is a good thing, but it can 
> make it hard to achieve full backwards compatibility.
> 
> I'll take a look at the convert.sh problem and see if I find a nice 
> solution.

FYI I now know what's wrong here - the problem is that the list of flags
including the defaults isn't being squashed, so we end up with something
like [UseFormat2, UseFormat1] being passed to commands.

Code which does things like UseFormat1 `elem` flags assuming they are
mutually exclusive goes wrong. I'm actually amazed that only one test
ran into this.

This would be fixed in the long-run by converting all commands to the
new options record style. In the shorter term we can hopefully force the
flags lists to be normalised by passing through oparse and ounparse.

Cheers,

Ganesh



More information about the darcs-devel mailing list