For future: `hash` generator

[Martin Janiczek]

Hello!

@gampleman made me aware of this repo. I'm very excited as to how it might remove lots of manual boilerplate writing and essentialy give us deriving! (I also like that the derived instance will be visible and tweakable, as opposed to Haskell ❤️ )

I have a package in works called elm-hash-dict. Right now I'm still working on it and finding the fastest implementation, but it's clear already that it will need a new (at least for Elm) abstraction: hash : a -> Int.

(Note I don't actually know if this will allow users to provide their own generators. I'm writing the rest of this post assuming there is a fixed set of builtins and nothing else can be generated. Hopefully that's wrong)

I'd like this hash abstraction to be code generated, to make usage of my future package easier!

I have some primitives in Hash.elm, based on Robin's implementation of FNV1a.

Right now I only deal with integers and strings when testing it so I don't have the complete picture in my head as to what the complete set of combinators is from which hashers for custom types and other things will be implementable. Snooping around this repo, I guess I need to conform to the CodeGenerator interface? As seen eg. in the Fuzzer builtin? Is there a minimum set of what I need to provide? (I expected a record to enforce presence but the generators are provided in a list instead...?)

Thanks for any help wrapping my head around this :)

[Jakub Hampl]

Yeah the documentation is still not complete so it can be a bit confusing.

In general the CodeGenerator interface has 2 important features to understand:

1. It automatically searches your codebase and dependencies for functions that fit its "pattern" and uses them in generated code. This allows you to elide some definitions from the interface, since they will be picked up automatically.
2. It allows modelling "partial" code generators in the sense that the generator isn't required to be able to generate code for every possible type. You can see for instance the toString generator really only works for enum like custom types.

If you want your code generator to be reasonably complete, then you should ensure it covers both records (typically this means implementing at least pipeline or combiner) and custom types (i.e. customType) and usually a bunch of data structures and primitives.

For a hashing implementation I would specifically orient my gaze towards the JSON Encoder generator, as its of the type -> thing pattern rather than the thing type pattern, which causes some differences in the code generation style (notably, everything is represented as a lambda and there is some built in simplification later on in the pipeline that removes some of the redundant lambda wrapping).