Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[#15] Add lenses for config-related types #17

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

nalkuatov
Copy link

@nalkuatov nalkuatov commented Jun 26, 2022

This adds common Lens types & operators and implements simple makeLenses template-haskell function to derive lenses for config-related types.
The tutorial's yet to be updated.

Description

Related issue(s)

Resolves #15

✅ Checklist for your Pull Request

Related changes (conditional)

  • Tests

    • If I added new functionality, I added tests covering it.
    • If I fixed a bug, I added a regression test to prevent the bug from
      silently reappearing again.
  • Documentation

  • Public contracts

    • Any modifications of public contracts comply with the Evolution
      of Public Contracts
      policy.
    • I added an entry to the changelog if my changes are visible to the users
      and
    • provided a migration guide for breaking changes if possible

Stylistic guide (mandatory)

Problem: It's quite unconvenient to access config-related records'
fields by hand, especially when it comes to nested ones.

Solution: Implement simple `makeLenses` function to derive lenses
for an arbitrary product type and add common lenses operators & types.
@nalkuatov nalkuatov force-pushed the nalkuatov/#15-add-lenses-for-config-with-th branch from 0158eca to a093735 Compare June 26, 2022 20:49
@nalkuatov
Copy link
Author

nalkuatov commented Jun 26, 2022

@Martoon-00
Is it worth having signatures for lenses?
We could have skipped the missing signatures warning for Base.hs, but I can't think of any troubles this can cause later on. What do you think?

@Martoon-00
Copy link
Member

Is it worth having signatures for lenses?

Hmhm, given that you already have field type available within makeLenses, does adding a signature constitute any difficulty?

I also don't see obvious troubles we could get, but would like to follow the practices here unless there is a major reason not to do so.

l ?= b = modify (l ?~ b)

(&~) :: s -> State s a -> s
s &~ l = execState l s
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I think actually we don't need operators and other helpers, especially if this is a functionality that we will have to cover with tests (we would really have to). We may need Lens type, but only if it will be used to define our new lenses.

The point is not to provide a simple replacement for lens library, but rather to be compatible with lens without depending on it. So that the user who wants to use our new lenses to configure the options, could use them along with lens package; and the user who does not want to use lens could go completely without them.

body = [| (\x -> $(record a fieldName [|x|]))
`fmap` $(appE (varE f) (appE (varE fieldName) (varE a)))
|]
record rec fld val = val >>= \v -> recUpdE (varE rec) [return (fld, v)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very-very good 👍

defLine = clause pats (normalB body) []
pats = [varP f, varP a]
body = [| (\x -> $(record a fieldName [|x|]))
`fmap` $(appE (varE f) (appE (varE fieldName) (varE a)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor suggestion: if you use appE in infix form here too, that should be slightly more readable.

TyConI (DataD _ _ _ _ [RecC _ fs] _) -> fs
TyConI (NewtypeD _ _ _ _ (RecC _ fs) _) -> fs
TyConI (DataD _ _ _ _ [_] _) ->
error $ "Can't derive lenses without record selectors: " ++ datatypeStr
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better use fail, error is for internal errors and will be reported respectively.

@nalkuatov nalkuatov requested a review from Martoon-00 July 5, 2022 10:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add lenses for config
2 participants