[Haskell-cafe] faster faster faster but not uglier (how to make nice code AND nice core)?

[Johannes Waldmann]

Dear Cafe,

* how to un-uglify the following program?
* and is it even ugly enough?

The following is some artificial example
but I think it illustrates some general questions -
for which I don't have answers. Do you?

I wanted a really fast implementation of a vector addition system
where the "vector" contains small numbers only.
and  I want it packed into a machine word
(and finally put these into Data.IntSet).
I can write this in low-level Haskell (I did),
and I could even use some low-level language (I also did)
but I was hoping that I don't need to.

https://gitlab.imn.htwk-leipzig.de/waldmann/tf/-/blob/master/TF4.hs#L108

* this is too low-level: This is for vectors of one fixed size -
but I want the code to be more generic,
and have the compiler do the specialization/unrolling.

* and not low-level enough: How do I tell GHC to pack (coerce?)
`data Pos` into `Word64`? (It's not
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#unpack-pragma
?)


And would it help? Or is it even needed?
If I have the data spread over several words,
it could still be fine - as long as it's kept in registers?

How can I then check that "it's fine"?
Yes I know, just look at the core. (That seems to be the ultima ratio of
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/hints.html#faster-producing-a-program-that-runs-quicker)

But is there/could there be some higher-level mechanism?
Perhaps a (type?) annotation that guarantees or checks
that core (locally) looks "good"? (does not allocate, ...)


NB: For the concrete application (evaluation of positions
in some game): 1. graph size is exponential, so a linear
speed-up won't really help. 2. brute-force gameplay
should be replaced by some symbolic evaluation and simplification.
That is in fact my goal. But - as long as we don't have this,
the program may be useful for generating conjectures.

- J.