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

Ben Franksen bugs at darcs.net
Sun Jun 23 17:57:54 UTC 2019


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

>> 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).
> 
> I think the Has typeclass is a good approach. Less keen on TH unless we
> have other compelling needs for it in darcs as well, it tends to make
> everything more complicated.

Lenses without TH mean /lots/ of boilerplate, though.

> For example binding group analysis is
> messed up by top-level splices which in my experience can lead to a lot
> of head-scratching, and it probably makes things less portable.
> 
> (For more detail on binding group analysis, see the comment "Top-level
> declaration splices break up a source file" in
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#template-haskell
> )

Ha! I've been stumbling over that problem a few times but didn't
investigate. I just found that moving all splices in a file together in
one place fixed it. Now I know why.

Yes, that's kinda ugly. But compared to all the boilerplate... we're
talking maybe several dozens of option values... plus any number of
configuration variables that we currently use the environment for.

>>> [ about implicit parameters]
>> I did some research to find out why they aren't popular. [...]
>> the meaning of a local definition can change depending on
>> whether it has a type signature or not.
> [...] I like using them in
> cases where no recursive use is contemplated. I think probably even
> expecting to need to rebind one (non-recursively) would be an indicator
> not to use them.

If this is the only problematic scenario, perhaps we could live with that.

>> 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.
> 
> TBH I don't see the difference. The Reader monad is just as dynamically
> scoped as implicit params: if you rebind the reader value you can get
> into just as much of a pickle, I think.

Yes, clearly. But with monadic code I am used to being careful about
effects and their order. When refactoring pure code I can be much more
ruthless and I don't want to loose that guarantee, i.e. the ability to
pick things apart and put them together in different ways, not having to
worry about effects and ordering.

>> 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.
> 
> Well, we'd need to put them in the type signatures of the class methods.

Good point. So this restriction doesn't bite as hard as I thought.

> But the same is true of using ReaderT

True.

>, or conversely if it's not true of
> using ReaderT, then the same is true of implicit params. I suspect it
> depends on whether we need the vars to *generate* a Doc or just to
> output it.

Just to output it. More precisely, to turn a Doc into a String or
ByteString that can then be written to some handle. And it only concerns
the interactive output; for the on-disk representation we always use the
plain printer that cannot be configured.

The env vars are all read inside getPolicy which is only called by
fancyPrinters, which in turn gets passed directly to the output
routines. This is so because getPolicy needs the handle to decide
whether to use colors and escaping by default: if it's a terminal device
than yes, else no.

So the constraint would not infect things like showPatch. We'd have to
see how to handle debug and error messages, though.

>>> For me the biggest problem with environment variables is that they are
>>> really problematic when using darcs as a library. [...]>>
>> (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.)
> 
> Agreed, and that's a far worse problem in that I run into it constantly
> when trying to code against darcs-the-library. Environment variables on
> the other hand are mostly a theoretical problem right now. Conventional
> wisdom has been that it (using CWD) is needed for performance reasons,
> but I don't know how true that is nowadays.

While this is indeed a problem, it is only tangential to configuration,
so I'd say we should discuss this one separately.

> My main argument for using the existing flags
> mechanism is avoiding having multiple overlapping mechanisms. But if we
> can clearly differentiate the two kinds of things and the
> overhead/boilerplate of adding flags is high, there's a strong argument
> for a new mechanism.

I remain undecided about this. And since I have lots of trouble ATM with
more dire problems like failing QC tests even for V3 I will postpone
work on this issue. Still, thanks for your input, if and when I take
this up again I will surely come back to it.

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


More information about the darcs-devel mailing list