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

[Ben Franksen]

Ganesh Sittampalam wrote:
> On 09/11/2014 14:40, Ben Franksen wrote:
>> Ganesh Sittampalam wrote:
>>> One
>>> question about that: why does recordConfig not use the same set of
>>> options as recordOpts?
>>>
>>> recordConfig :: [DarcsFlag] -> RecordConfig
>>> recordConfig = oparse (recordBasicOpts ^ O.verbosity ^
>>>                            recordAdvancedOpts ^ O.useCache) RecordConfig
>>>
>>> recordOpts = recordBasicOpts `withStdOpts` recordAdvancedOpts
>>>
>>> Is it because some options are handled by the infrastructure so don't
>>> need to be in RecordConfig?
>> 
>> Yes, exactly. Using recordOpts we would have to add (even) more fields to
>> recordConfig (like e.g. for the help option) which are not needed inside
>> the command implementation, since they are already handled, as you
>> stated, by the infrastructure. The decision is certainly debatable: maybe
>> adding the extra fields is the smaller evil.
> 
> I've just been playing around with this a bit more. One question about
> withStdOpts:
> 
> withStdOpts :: DarcsOption (Maybe StdCmdAction -> Bool -> Bool
>                                -> Verbosity -> Bool -> b) c
>             -> DarcsOption (UseCache -> Maybe String -> Bool
>                                -> Maybe String -> Bool -> a) b
>             -> DarcsOption a c
> withStdOpts basicOpts advancedOpts =
>   basicOpts ^ stdCmdActions ^ anyVerbosity ^
>   advancedOpts ^ useCache ^ hooks
> 
> Is the order that the options are composed in important or could it be
> reordered so that basicOpts and advancedOpts are next to each other?

I think it can be safely re-ordered. I chose the ordering so that it is the 
same as the one in commandAlloptions, which is the same (I think) as the one 
in which the options are displayed with --help. But there is no real reason 
I can see to keep it that way.

> I'm not entirely sure where I'm going with this question, just want to
> know how much scope there is to play around here.
> 
> I'm also in favour of your other point, if we can make it work:
>> Another (raw) idea I had: instead of making the distinction between
>> advanced and basic options per command, could we get away with
>> classifying the options themselves? The distinction is only there to
>> guide the help output, which is completely handled by the infrastructure,
>> the command implementation couldn't care less; except that we currently
>> decide per command what is a basic and what is an advanced option.

There is an idea I had today, inspired by two ICFP 2014 papers [1][2].

One can view the new options system as a very simple embedded DSL. The way 
it is implemented now is as a /shallow/ embedding: an option directly 
implements the semantics as a 4-tuple of interpreter functions. What if we 
turn it into a /deep/ embedding instead, i.e. as an abstract syntax tree? 
When I wrote it I did not think this was possible without employing heavy 
type machinery, but the two papers have convinced me that this is not the 
case. Indeed, such a deep embedding would have a simple structure: it would 
be a type indexed list, where the indices of adjacent elements have to match 
up, exactly as when using the ^ operator. Darcs already uses something quite 
similar to represent lists of patches index by repository contexts, so that 
the type system ensures that the contexts match up.

The advantage is that it would now be much easier to add new 
interpretations, and especially /non-compositional/ interpretations, such as 
removing certain options if they are handled by the infrastructure, 
attaching labels (such as basic/advanced) to options etc.

I think I'll play with this a bit in the next days and let you know how it 
works out.

[1] "Folding Domain-Specific Languages: Deep and Shallow Embeddings"
    by Jeremy Gibbons and Nicolas Wu

[2] "Reflection without Remorse: Revealing a hidden sequence to speed up
    monadic reflection" by Atze van der Ploeg and Oleg Kiselyov. (They use
    type indexed sequences for chains of monadic binds)

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." -- Scott Adams