Vladislav Zavialov

Turns out, it’s something in `static-haskell-nix` specifically that causes `libdevil` to fail. The build failure could not be reproduced with upstream `pkgsMusl`, see https://github.com/NixOS/nixpkgs/issues/132218#issuecomment-890372968 So my fix (adding `libdeflate` to...

You can extract `SomeTypeRep` from `WrapTypeable`, can you not?

> Can I? `Type.Reflection` is still mostly voodoo to me. I assumed that since they're stored separately in the `TypeRepMap` (`trAnys` vs. `trKeys`), they're not trivially convertible. The elements of...

I'd like to use https://hackage.haskell.org/package/inspection-testing to check that `named` optimizes away completely when the function application is saturated.

This should be addressed by [GHC Proposal #40: Unrestricted Overloaded Labels](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0040-unrestricted-overloadedlabels.rst). For the time being, I believe you can use `fromLabel`: ``` fn ! fromLabel @"my-arg" 5 ```

I'm not sure. It doesn't seem like something with good ergonomics, why use `fromLabel @"my-arg"` instead of `#my_arg`?

Alas, I don't think `named` (or any other library) can work around this GHC restriction.

> both of these libraries define orphan instances for No, `named` doesn't define an orphan, but `generic-lens-labels` does. The solution I'd prefer is that `generic-lens-labels` doesn't define an orphan.

> Or does the conflict still exist by virtue of that lib having orphans? I didn’t try to use both libs together, but I predict there should be a conflict....

> As far as I am concerned `IsLabel name (a -> Param p)` is absolutely an orphan. Then you're using a different definition of an orphan instance, definitely not the...