[darcs-devel] [patch1883] get rid of unused ShowDictRecord (and 2 more)

Ben Franksen bugs at darcs.net
Tue Aug 27 10:10:33 UTC 2019


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

>>> We can certainly inline bits of other packages we want to use,
>>> but 'constraints' isn't a big dependency
> 
>> Not as big as some of the others, true. I just counted: 6 modules
>> exporting 190 symbols. Of which we need one.
> 
>> I remember one guy complaing on @darcs-users about having to download &
>> compile what feels half of hackage... I feel that too, whenever I switch
>> to a new compiler version.
> 
>> What other packages did you have in mind?
> 
> Nothing in particular, but now I look, 'hashable',

Hm, yes. This one's also quite dubious.

It is only used for the patience diff. I may be wrong but it looks as if
they manually implemented a hash table there, with linear lookup in case
of a hash collision. This should be refactored to either use
Data.HashMap (another dependency, though I'd say justified if it gives
us better performance here) or else use a plain Map with ByteString keys
(if Data.HashMap doesn't perform better).

BTW, the diff algorithms are severely under-tested. We should add
properties and test them!

> 'filepath',

>From that library we use at least

</>
<.>
combine
dropFileName
dropTrailingPathSeparator
isAbsolute
isRelative
isValid
joinPath
normalise
pathSeparator
splitDirectories
takeDirectory
takeFileName

Obviously justified by the number of symbols alone. It also takes care
of doing the right thing for each OS. I know, I know, we still have to
be very careful whether to use the native or the Posix module (more
often than not it's the Posix module). Still better than doing all this
stuff ourselves. (And in some places we still do; yet another TODO item.)

> 'data-ordlist'

We import nubSort, isect, minus from that one. These functions are not
very complicated but also not completely trivial to get right, so I'd
say the dependency is justified.

> 'html' (The latter dependency is in fact a bit dubious
> as we're actually using it for XML output)

Yup. Should use a proper XML lib here. Generating correct XML is also
not trivial (text must be properly encoded), so I'd say a dependency is
justified. From a quick search it looks as if
http://hackage.haskell.org/package/X could fit our needs. I may give it
a try.

, 'split' (actually that might
> really be not used - but if we were using just one function from it
> the same argument would apply).

We don't use it and I will remove the dependency (of darcs-test on split).

> We can distinguish 'constraints' from these others because there's really
> only one way to write that type, so I would accept that it's at one extreme
> of the spectrum.

I also don't like the name of the data type. All the libraries above
export functions that by their name alone give a good indication of what
they will do. Not so with 'Dict'. You need to know about the semantics
of classes in terms of its translation to passing a dictionary of
methods in order to "intuitively" grok what 'Dict' is about. And someone
who comes from Python will most certainly be confused...

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


More information about the darcs-devel mailing list