Record fields list

[turboMaCk]

Following the alias -> record rename #116 this PR aims to make record representation more accurate

Support for {} records on elm side (these are very important in elm as they're core part of extensible records). This type of record is never derived by generics instance but it can be defined by hand. This makes representation of ElmRecord closer to real elm record which might become handy in the future.

In JSON, empty record is represented by [] to make implementation compatible with aeson deriving.

[turboMaCk]

Important comment

[turboMaCk]

decodeStrict @RecordUnit "[]" 
Just RecordUnit

[turboMaCk]

toJSON $ RecordUnit
Array []

in theory we can fail here unless json contents empty array. Not if there will be any advantage though.

[turboMaCk]

I'm not really excited about this. Any idea?

[turboMaCk]

manual instance implementation of record with no fields.

[jhrcek]

I'm not very fond of this change.
Is there any actual use case for empty records that you envision we'll be using (as opposed to try to tightly support all what elm allows)?
Can you give a small example of how you'd take advantage of this on the elm side?

[turboMaCk]

I think it's better to represent elm types close to how elm represents it. Modeling record fields as non empty values is simply wrong. I assume one of the reasons was for support of elmRecordIsNewtype (which is also not producing accurate representation of newtype in Elm). Regular records are sort of compatible with empty records out of the box.

The other advantage is that list is simpler to define than nonempty list so this also removes a bunch of noise from manual declaration of elm record (which I think is especially annoying since it should not be required).

Where this might be handy later is if we get to same feature where we would start utilizing elm's extensible records for one reason or the other. I outlined one of the possible use-case in #45 (comment). I don't expect it to be something we implement but this change would be required for it as well as any other feature that would manipulate records in similar way.

I don't think there is any nice elm code I can show because in the end one can always do Json.Decode.map (always {}) generatedDecoder already anyway. This is not as much about of what one can do on elm side as it is about what elm-street could generate and how user can define Elm instances.

Try to think about it. I know it might seem contra intuitive to see advantage of adding a special case but I think in long run this should lead to elimination of special cases. Especially if we get to implementing truly unboxable and type safe newtype generation.