Unify hash Base encoding/decoding funcitons

[Anton-Latukha]

Minimal start on refactoring the module interface step-by-step towards Cryptonite migration.

[sorki]

Looks reasonable - maybe we can drop encodeBaseXY altogether and use encodeIn, decode instead (encodeBase | decodeBase sounds even better).

There are only a few places that use *codeBase16 *codeBase32 outside of the module.

Can you please rebase on master? It needs adding qualified B32 in test.

[sorki]

After rebase you can cherry-pick sorki@b26a815

[Anton-Latukha]

Interesting encounter:

-- Old code:
encodeBase32 :: Digest a -> T.Text
-- New code:
encodeIn Base32 :: Digest a -> T.Text

Recieves:

tests/Hash.hs:44:17: error:
    • Cannot apply expression of type ‘Digest a0
                                       -> Data.Text.Internal.Text’
      to a visible type argument ‘StorePathHashAlgo’
    • In the first argument of ‘shouldBe’, namely
        ‘((encodeIn Base32) @StorePathHashAlgo (hash exampleStr))’
      In a stmt of a 'do' block:
        shouldBe
          ((encodeIn Base32) @StorePathHashAlgo (hash exampleStr))
          "xv2iccirbrvklck36f1g7vldn5v58vck"
      In the second argument of ‘($)’, namely
        ‘do let exampleStr
                  = "source:sha256:2bfef67de873c54551d884fdab3055d84d573e654efa79db3"
                      <> "c0d7b98883f9ee3:/nix/store:myfile"
            shouldBe
              ((encodeIn Base32) @StorePathHashAlgo (hash exampleStr))
              "xv2iccirbrvklck36f1g7vldn5v58vck"’
   |
44 |       shouldBe ((encodeIn Base32) @StorePathHashAlgo (hash exampleStr))
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I need to lookup, more what it is about, on the face seems really strange.

[sorki]

Type application @StorePathHashAlgo has to be the first "argument".

Your type is encodeIn :: BaseEncoding -> Digest a -> T.Text which due to ScopedTypeVariables (which implies ExplicitForAll) gets rewritten to encodeIn :: forall a . BaseEncoding -> Digest a -> T.Text and using TypeApplications you need to apply algorithm to a type var so it's not ambiguous.

[Anton-Latukha]

Probably for you it is something obvious, but for me - it is completely obscure and needs reading.

Since the promise of functions being the first class, the equivalent function sectioning should be equivalent. Thanks for the pointer into the direction to understand.
I definitely need to look deeper into quantifiers and types.

Currently the easiest/prettiest solution - is to where the section application 🤣

[Anton-Latukha]

Ok.

I got the interplay between the language extensions and quantifiers.

I forgot what ScopedTypeVariables does, thou the name is instructive when one remembers.

The caveat seems to be that visible type application happens to an invisible type argument that GHC exposes to a declared or annotated function, otherwise, GHC seems to not give access to the invisible type application argument before argument.

[sorki]

Cool, I've learned about this while working on this codebase and toying with polysemy and my toy polytype lib on top of it. It takes some time to get used to type level programming in Haskell :-)

[sorki]

Type level programming in Haskell:

Me: So how many extensions do you want?
GHC: Yes.

[Anton-Latukha]

TypeApplicaton with DataKinds is a strange beast.

I want my kinds to be * -> * and even better - sometimes polymorphic, so * accepts everything. I want my kinds to be * and * -> * not HashAlgorithm suddenly. What is a Hash Algorithm kind, not calling the harder cases. When types suddenly become not types and kinds suddenly become not kinds - how I should think about them.

DataKinds is an extension from the dependent types lambda space, btw "Giving Haskell a Promotion" has an argumentation against dragging-in all functionality from dependent types.

I am OK and cool with native lambda field extensions.
And as I see, dependent type extensions need to be used one, to several at a time in an enclosed environment. If someone somewhere wants to go full dependent types - do that in self-enclosed environment so the interface is classic Haskell (typed parametric lambda calculus). Because DT extensions may easily slip across the project - and suddenly the code is harder and becomes rigid, not refactorable and refactoring becomes not evolution but a ripping-out of that system.

[Anton-Latukha]

Also many of the extensions are shown and discussed/copy of one trivial spiel in a lab coat.
And nobody explained what that extension can be effective for "in life application". What field of application are well-known to get much from it. What are classical occurrences where TypeApplication with DataKinds really make code more performant and to what degree, I understand that it allowed to move some computation to compile-time, but newcomer needs to know "how much" comparing to the cost of the introduced code rigidity and complexity. And it is impolite to ask the implementation author about it, if newcomer can read it in the newspaper (documentation).

[sorki]

I would prefer encodeBase | decodeBase naming, decode is rather ambiguous (e.g. used by Cereal and tons of other libs).

[Anton-Latukha]

I agree about encode/decode being too generous here.

The root cause for me is - encode/decode are general names, but suddenly they do only the Base encoding.

And in functions which purpose from the name (and from the type) is ambiguous - I like to indicate the direction. While decodeBase is grammatically correct - and encodeBase - "encode the base", or "encode into the base" - that is why using encodeIntoBase or more pidgin minimalistic encodeInBase - it creates minor inconvenience for the writer, but it gives ease and right understanding during reading, so tend to insert that to remove the ambiguity.

[Anton-Latukha]

This seems good enough.

[sorki]

Looking good, just two nitpicks.

[sorki]

Thank you!

[Anton-Latukha]

Thank you also.