juspay / jrec

Literally the best anonymous records

jrec — anonymous records for busy people

Based on superrecord, but simplified. No automatic field reordering. No GHCJS bits inside. Easier to hack on.

Benefits

• Nice construction syntax:

  Rec (#id := 18853, #orderId := "MG13-233")

• Provides Generic instances out of the box. Aeson, etc can't believe these aren't normal records! Anything Generic-derived just works.

• Provides generic-lens and generic-optics instances out of the box. Due to those custom instances, we support polymorphic updates.

• O(1) field access, O(n) construction.

• PureScript-style partial records — if you have a Rec ("foo" := Int ': rest), HasField "foo" will work just fine.

Developing

IDE support is available inside nix-shell. For example, if you use VS Code, you may launch it as:

nix-shell --run "code ."

Tests

Run bin/test for fast-reloading tests. When library sources change, the test script will reload instantly and re-run the tests.

TODOs

• Documentation.
• Expose all internals.
• -- NOTE: doesn't use 'KeyDoesNotExist' — fix this.
• RemoveAccessTo — can we get rid of it?

Acknowledgement

• The JRec.Internal module is entirely based on the code from superrecord.

jrec's Issues

Rename JRec.Super to JRec.Internal and expose it?

We need the internals to be exposed for Juspay + it's useful overall

Make sure there's a better error for Rec (a,b,)

Currently the error will probably be bad. We can add an instance for (x -> y) with a TypeError => that will warn about the trailing comma issue.

Convert the flake to use haskell-flake

https://haskell.flake.page/

Allow customizing the omitNothing behavior?

Currently we always remove null fields during encoding, and always allow skipping them during decoding.

Expose JRec.Tuple as JRec.Internal.Tuple

Ord (Rec lts) instance

I'm going to create a PR. It shouldn' t be hard since there is already an Eq insatnce.

JRec.Tuple compiles super slowly with GHC 8.10

[Question] Stance about key duplication

I have a question about the stance of the library against key dupclication.

Currently, there is no key duplication check on construct, and the operators work even if there is a key duplication.
There is a metion in the README about fixing KeyDoesNotExist and RemoveAccessTo, which I guess you want to get rid of key duplication. But then there are operators like append that could bring in key duplication.
So which stance does the library have(or will have) against key duplication?

1. Prevent key duplication by adding key check constraints on construct functions/instances and make sure operations don't bring in key duplication.
2. Adding key check constraints are costly, so don't. Make the operation works even if there ia an accidentaly brought in key duplication.

Add a `flake.nix`

Convert the default.nix to a flake.nix such that nix build builds the package and nix develop puts us in a development shell where both cabal build and haskell-language-server commands run and succeed.

Ref:

• https://nixos.wiki/wiki/Flakes
• https://nixos.wiki/wiki/Haskell

Expose useful things like 'get' in the main JRec module

Better errors when value types don't match?

> Rec (#a := 3, #b := True) :: Rec '["a" := Int, "b" := String]

<interactive>:1:1: error:
    • Couldn't match type ‘Bool’ with ‘[Char]’
        arising from a use of ‘Rec’
    • In the expression:
          Rec (#a := 3, #b := True) :: Rec '["a" := Int, "b" := String]
      In an equation for ‘it’:
          it = Rec (#a := 3, #b := True) :: Rec '["a" := Int, "b" := String]

Is it possible to provide the key in the error message as well?

CI for GHC 8.8 and GHC 8.10

Merging and consing

Vague inspiration: https://pursuit.purescript.org/packages/purescript-record/0.2.6/docs/Data.Record

Not sure about all of this, but:

• union appends records and removes duplicates. Left-biased. Does not sort.
• append appends records and does not remove duplicates.
• insert adds a field to the beginning, but checks that the record does not contain that field already.
• insertOrSet adds a field to the beginning, or replaces the existing field.

There have to be tests for all of these, including

• should-not-typecheck tests for insert.

added by srid:

• Fix a bug with append overwriting values (looks to affect Eq as well; ultimately because of RecTyIdxH)
• Finish tests