Skip to content

GitLab

GHC
GHC
Open
Opened by Sebastian Graf@sgraf812Developer

Integrate a minimal lens library with GHC

Motivation

Numerous times I've wanted a lens library in GHC. Here's a recent example of that: At some point (and one too many refactorings of all call sites) I got tired of all the lookupVarInfo/setEntrySDIE stuff happening in that module that I wrote overVarInfo (which should actually have been called lensVarInfo or varInfoTraversal). But these ad-hoc traversals are all a bit too clumsy to use without a few essential lens combinators. Which I'm not going to put in that module, because it has nothing to do with the problem domain there, also it's common vocabulary that could be shared by many more modules.

Proposal

Use (and/or define) lenses within GHC, for certain (more below) tasks. These are the options I can think of:

  1. Use/re-export the lens implementation of Cabal. Pros: No additional dependencies, probably more than we'd ever need or are willing to incorporate. Cons: Weird namespace to import from within GHC, but we could provide an alias or re-export it from GHC.Prelude. (Adding lenses to Cabal was an idea of @phadej, I think.)
  2. Rip code from microlens (2a) or add it as a boot package (2b). It's BSD-licensed, and I'm hopeful that Artyom would be supportive. Pros: cleaner than (1). Cons: (2a) needs to compile more stuff, (2b) adds the maintenance overhead of a boot package.
  3. Depend on optics-core as a boot package. Same as (2b), but an even larger package, judging from hackage. Also hasn't been around for as long as the traditional Van Laarhoven lenses.

Despite the architectural hackiness, I'm in favor of (1), I think.

Concerns

  1. Performance: Making it easy to do deep lens traversals might invite the user to do multiple traversals where one would suffice. Apart from these concerns being premature, I think they can easily be fixed in code review and these changes are very simple to backport in case of a looming performance regression. Apart from that, I think similar concerns apply to the use of deterministic unique sets/maps, which often incur an additional log n factor that one might not be aware of.
  2. Perceived Code Complexity increases, because you might not know how a particular lens is implemented under the hood. Which may lead to performance regressions as in concern (1).
  3. "I for one appreciate the simple haskell large parts of ghc are written in." I agree that's an issue for extensive use of lenses, but I'm beginning to think that my use case is much more narrow, for cases like in the motivation section, where lenses are simply a matter of separation of concerns.
Edited by Sebastian Graf