{"action":"created","issue":{"url":"https://api.github.com/repos/purescript/purescript/issues/1867","repository_url":"https://api.github.com/repos/purescript/purescript","labels_url":"https://api.github.com/repos/purescript/purescript/issues/1867/labels{/name}","comments_url":"https://api.github.com/repos/purescript/purescript/issues/1867/comments","events_url":"https://api.github.com/repos/purescript/purescript/issues/1867/events","html_url":"https://github.com/purescript/purescript/issues/1867","id":131701129,"number":1867,"title":"Idea: Single record restriction for data constructors","user":{"login":"libscott","id":125019,"avatar_url":"https://avatars.githubusercontent.com/u/125019?v=3","gravatar_id":"","url":"https://api.github.com/users/libscott","html_url":"https://github.com/libscott","followers_url":"https://api.github.com/users/libscott/followers","following_url":"https://api.github.com/users/libscott/following{/other_user}","gists_url":"https://api.github.com/users/libscott/gists{/gist_id}","starred_url":"https://api.github.com/users/libscott/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/libscott/subscriptions","organizations_url":"https://api.github.com/users/libscott/orgs","repos_url":"https://api.github.com/users/libscott/repos","events_url":"https://api.github.com/users/libscott/events{/privacy}","received_events_url":"https://api.github.com/users/libscott/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2016-02-05T17:22:48Z","updated_at":"2016-02-15T22:43:22Z","closed_at":null,"body":"One bottleneck that I've found in my code has been due to the lack of a field accessible record type that supports instances. Related issues are #1822, #1675, and maybe others. What I'd like to have is all of the following:\r\n\r\n* Fields accessible by automatically generated `.label`s\r\n* First class type that supports instances, especially Generic derivation.\r\n* Javascript friendly data representation.\r\n\r\nTo illustrate:\r\n\r\n```Haskell\r\nnewtype A = A {x::Int, y::Int}\r\n\r\na = A {x:1,y:2}\r\nb = a.x -- Can't do this\r\n\r\na' = case a of (A r) -> r -- Have to pattern match to make a useful.\r\n```\r\n\r\nRegarding Javascript friendliness, the objective would be to reduce the usage of `valueN` fields in the data. The newtype solution is good until you need polymorphism. And in the case that you do need to change a `newtype` to a `data` record, you have slightly less Javascript to change. In Haskell/Purescript you have to pattern match to get at the value but in Javascript it's not so meaningful, because since there's no branching required ie `someEitherValue.value0` there's no additional safety.\r\n\r\nAnother observation:\r\n\r\n```Haskell\r\ndata A = A {a::Int} {b::Int}\r\n```\r\n\r\n`A` Is not legal Haskell, but it IS legal Purescript. Would it not be a valid solution to this issue to do it the Haskell way and just allow one Object (or a sequence of non object fields) per data constructor, and skip the wrapper object entirely for this case? Ie, a `data A = A {x::Int,y::Int}` becomes a Javascript object of type `A` with properties `x` and `y`.\r\n\r\nEdit: and since you can only have one record, you can also allow label accessors to work directly since there's no ambiguity on which record you want to access.\r\nThoughts?"},"comment":{"url":"https://api.github.com/repos/purescript/purescript/issues/comments/184427281","html_url":"https://github.com/purescript/purescript/issues/1867#issuecomment-184427281","issue_url":"https://api.github.com/repos/purescript/purescript/issues/1867","id":184427281,"user":{"login":"paf31","id":630306,"avatar_url":"https://avatars.githubusercontent.com/u/630306?v=3","gravatar_id":"","url":"https://api.github.com/users/paf31","html_url":"https://github.com/paf31","followers_url":"https://api.github.com/users/paf31/followers","following_url":"https://api.github.com/users/paf31/following{/other_user}","gists_url":"https://api.github.com/users/paf31/gists{/gist_id}","starred_url":"https://api.github.com/users/paf31/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/paf31/subscriptions","organizations_url":"https://api.github.com/users/paf31/orgs","repos_url":"https://api.github.com/users/paf31/repos","events_url":"https://api.github.com/users/paf31/events{/privacy}","received_events_url":"https://api.github.com/users/paf31/received_events","type":"User","site_admin":false},"created_at":"2016-02-15T22:43:22Z","updated_at":"2016-02-15T22:43:22Z","body":"> I would happily use them if they were baked into the langauge, that would be way cool IMO, but thats another story...\r\n\r\nI agree it'd be cool, but I'm not sure how to implement them while keeping things composable. What would the runtime representation be?"}}