Taylor Fausak

Great! I feel like we've landed in a spot where we all more or less agree. Just to make sure we're all on the same page, I'm going to say...

👍 I'd happily accept a PR for improving performance. Bonus points for a benchmark that actually shows the improvement.

I wonder if it would be sufficient to change how these operators are defined. The current definitions are perhaps overly verbose. ``` hs -- current x |> f = apply...

For what it's worth, package authors can use the `--pvp-bounds both` flag when uploading packages to properly set the bounds. https://www.fpcomplete.com/blog/2015/09/stack-pvp/ https://docs.haskellstack.org/en/stable/yaml_configuration/#pvp-bounds

Nice! The tests only show `rts-options` taking a string. Does it also allow for lists like `ghc-options` does (IIRC)?

`stack new` can do this. It draws from [stack-templates](https://github.com/commercialhaskell/stack-templates). Or you could use [hi](https://github.com/fujimura/hi) if you don't like Stack.

That's what [hpack-convert](https://github.com/yamadapc/hpack-convert) did, but it hasn't been updated in a while.

Are you talking about this? https://github.com/sol/hpack/issues/303#issuecomment-700905674 If so, the workaround is mentioned prominently in the README as of #404: https://github.com/sol/hpack/blob/f1aa0c48eb696d66be8c1bcf68528253eab09178/README.md#handling-of-paths_-modules That being said, it might be nice to have it...

Seriously though, supporting hashes for GHC options might be nice. It could help with problems like #182 too. ``` yaml ghc-options: -with-rtsopts: -N ```

Ah, that explains the `HLint.hs` references in the documentation! I was wondering. Your analysis makes sense to me, and your proposed solution seems plausible. The only other thing I have...