Skip to content

Implement tuples as syntax sugar for newtype for record types#556

Closed
andreypopp wants to merge 1 commit intopurescript:masterfrom
andreypopp:tuples
Closed

Implement tuples as syntax sugar for newtype for record types#556
andreypopp wants to merge 1 commit intopurescript:masterfrom
andreypopp:tuples

Conversation

@andreypopp
Copy link
Copy Markdown
Contributor

Discuss!

Tuples are represented as

newtype TupleX a b ... = { _1 :: a, _2 :: b, ... }

This commit implements a desugaring pass which translates TupleLiteral values
and TupleBinder binders into AST corresponding to chosen representation.

It's OK If you are not going to merge this. Anyway, I gained more understanding of PureScript internals.

Tuples are represented as

    newtype TupleX a b ... = { _1 :: a, _2 :: b, ... }

This commit implements a desugaring pass which translates TupleLiteral values
and TupleBinder binders into AST corresponding to chosen representation.
@andreypopp
Copy link
Copy Markdown
Contributor Author

Actually if would be more useful to represent tuples as type instead of newtype so we have accessors for free (I don't know how to implement them now). But this would rule out type class instances for tuples.

Related question: is that possible to make type classes work for records with a closed row type?

@joneshf
Copy link
Copy Markdown
Member

joneshf commented Aug 10, 2014

Actually if would be more useful to represent tuples as type instead of newtype so we have accessors for free (I don't know how to implement them now). But this would rule out type class instances for tuples.

There's no need for that. One clean option is to use a lens for this. Unfortunately something was broken the last time I tried to use this: https://github.com/purescript-contrib/purescript-lens/blob/master/src/Control/Lens/Tuple.purs#L17-L33

@paf31
Copy link
Copy Markdown
Contributor

paf31 commented Aug 11, 2014

I love how you were able to implement this purely as syntactic sugar for records.

I wonder if it would be better to just use type synonyms, which would allow arbitrarily large tuples (record types would just be generated on the fly).

We can't do type class instances even for closed rows right now. My reason is that I interpret "extensible records" to mean "labels have no fixed semantics", and attaching type class instances would violate that in my opinion. I'm open to discussion about it though.

@hdgarrood
Copy link
Copy Markdown
Contributor

Now that #863 has been merged, I guess it's feasible to have something like this approach but with type synonyms rather than newtypes (generated on the fly, in that desugar step?) How would you feel about that?

@paf31
Copy link
Copy Markdown
Contributor

paf31 commented Feb 21, 2015

I'm not sure how I feel about it, honestly. I think records are superior to tuples in every regard apart from the lack of support for instances (even #863 won't let us define a Show instance for a tuple for example), and I don't think it's a good thing to encourage users to use tuples. But, they are definitely handy sometimes.

@paf31
Copy link
Copy Markdown
Contributor

paf31 commented Apr 4, 2015

With the Data.Tuple.Nested changes, I'm thinking I should close this.

@garyb
Copy link
Copy Markdown
Member

garyb commented Apr 6, 2015

Yeah, I think so. I still do occasionally wish for native tuples, but that's usually after I've been writing a lot of Haskell again ;) I can definitely live with our version.

@paf31 paf31 closed this Apr 6, 2015
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.

5 participants