[darcs-devel] [issue2602] add command 'darcs config'

[Ben Franksen]

Ben Franksen <ben.franksen at online.de> added the comment:

>> The obvious solution is to hide such options in the help output [...]
> 
> I agree with this. (I guess there ought to be some signpost to them
> somewhere in the help.)

Of course.

>> Then there is the technical problem of how to pass such options down to 
>> where they are needed. [...]
> 
> I'm not keen on ReaderT Config IO because we'll be passing the whole
> config to places where only one value might be needed
In https://www.fpcomplete.com/blog/2017/06/readert-design-pattern
under the heading "Has typeclass approach" he describes how to use type
classes to avoid this. He also describes how we can let TH generate all
the boilerplate using the lens library (I checked that the example works
equally well with microlens).

The way HasX constraints propagate upward from the point of use is
actually pretty similar to implicit parameter constraints. The main
difference is that with ReaderT we are forced to use monadic style,
whereas with implicit parameters we aren't. But if we want to replace
env vars we already are in the IO monad, so that wouldn't make a
difference for us.

> My personal
> preference would be implicit parameters, but I know they aren't
> generally popular.

I did some research to find out why they aren't popular. It seems that
there are some good reasons. This discussion:

https://www.reddit.com/r/haskell/comments/6gz4w5/whats_wrong_with_implicitparams/

is an interesting read with some quite scary examples. Most
disturbingly, the meaning of a local definition can change depending on
whether it has a type signature or not. This is also mentioned in the
ghc manual here:

https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#implicit-parameters-and-polymorphic-recursion

One reason I tend to like the ReaderT approach more is precisely
/because/ it enforces monadic style. Allowing dynamically scoped
variables in arbitrary (pure) code scares me a lot because they make
reasoning (in particular: refactoring) much more difficult.

On the practical side, I have read that you are not allowed to use
implicit parameter constraints as superclass constraints for classes or
instances (because that introduces incoherence). This is what E. Kmett
says here:

https://www.reddit.com/r/haskell/comments/5xqozf/implicit_parameters_vs_reflection/

I may be wrong but i think we would need to do exactly that in order to
remove the environment variables that configure the behavior of our
Printer type, since that functionality is used by generic code under
Darcs.Patch.

BTW, the reflection library is something I haven't been able to wrap my
head around. I look at the API and I can't see how to use it to achieve
what it claims. If you happen to understand it, I would like to see the
ReaderT example from the link above transscribed to use reflection instead.

> For me the biggest problem with environment variables is that they are
> really problematic when using darcs as a library. The calling code
> doesn't know about them and even it it did it's not exactly a pleasant
> API to have to set an environment variable before calling a function.

Good point. Global (environment or in-program) variables are always a
bad choice for libraries.

(BTW, this also applies to the current working directory which you have
to initialize properly for most procedures from Darcs.Repository and
Darcs.UI.Commands; unless we completely remove the assumption of "."
being the current repository from them.)

>> We can solve all three problems with one stroke by adding two more 
>> configuration files for Darcs: _darcs/prefs/environment and 
>> ~/.darcs/environment. [...]
> 
> This makes it hard to set them on a per-invocation basis. I barely use
> them anyway, but when I do it's by doing something like
> 
>   DARCS_SOMETHING=yes darcs ...
> 
> I may be atypical because I'd normally just be experimenting for
> development purposes rather than actually having decided I need them
> permanently.

True. I didn't think of that either.

(BTW, I use that idiom, too, though for a different purpose. I have
DARCS_ALWAYS_COLOR=1 by default because I like to pipe things through
less (directly or let darcs do it) which understands color codes. So I
need to disable that when redirecting the output to a file...)

To circumvent this problem, we could add /just one/ additional option
--config "VAR=value" that can be given multiple times to override any of
the settings on a per-invocation basis.

Your other objections still stand, of course.

Cheers
Ben

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/issue2602>
__________________________________