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

Record puns #867

Closed
anttih opened this issue Dec 21, 2019 · 14 comments
Closed

Record puns #867

anttih opened this issue Dec 21, 2019 · 14 comments

Comments

@anttih
Copy link

@anttih anttih commented Dec 21, 2019

I'd like to propose new syntax for record literals:

{ key } = { key = key }

So, for example:

let key = "value" in { key } : { key : Text }

I think this greatly reduces noise when returning a big record.

@sjakobi sjakobi added the enhancement label Dec 21, 2019
@sjakobi

This comment has been minimized.

Copy link
Collaborator

@sjakobi sjakobi commented Dec 21, 2019

For reference: This is kind of the inverse of #74.

This looks like it could be easy to standardize and implement since it appears to be just syntactic sugar:

{ x } is syntactic sugar for { x = x }.

It might slightly complicate parsing though, I'm not quite sure.

@sjakobi

This comment has been minimized.

Copy link
Collaborator

@sjakobi sjakobi commented Dec 21, 2019

I guess we'd also want to allow mixed use of puns and classic record field syntax:

let foo = 1

in { foo, bar = 2 }
@SiriusStarr

This comment has been minimized.

Copy link
Collaborator

@SiriusStarr SiriusStarr commented Dec 21, 2019

This partially alleviates #866 as well, since it makes constructing records very convenient (as long as one can match the field names, which is often the case). I'm a fan.

@sjakobi

This comment has been minimized.

Copy link
Collaborator

@sjakobi sjakobi commented Dec 21, 2019

On second thought, maybe it's not that easy to implement: After parsing, you'd have these record literals where some fields have values and some don't, but after type checking you'd rather work with records where each field has a value…

@Nadrieril

This comment has been minimized.

Copy link
Collaborator

@Nadrieril Nadrieril commented Dec 21, 2019

@sjakobi If it's just syntactic sugar I'd expect it to get expanded before typechecking, so that only parsing has to change.

@Gabriel439

This comment has been minimized.

Copy link
Contributor

@Gabriel439 Gabriel439 commented Dec 22, 2019

This is something I've wanted for a while

I also agree with @Nadrieril that this could be treated as syntactic sugar

@Profpatsch

This comment has been minimized.

Copy link
Member

@Profpatsch Profpatsch commented Jan 19, 2020

I really want that!

@sjakobi

This comment has been minimized.

Copy link
Collaborator

@sjakobi sjakobi commented Jan 19, 2020

@anttih Would you be interested in standardizing this yourself?

A proper proposal should probably be accompanied by an implementation. If that first implementation were in Haskell, I (and probably Gabriel too) would be happy to assist with advice.

@anttih

This comment has been minimized.

Copy link
Author

@anttih anttih commented Jan 20, 2020

@sjakobi Unfortunately I don't have the time currently.

@Nadrieril

This comment has been minimized.

Copy link
Collaborator

@Nadrieril Nadrieril commented Mar 10, 2020

I'm planning on doing this soon

@Nadrieril

This comment has been minimized.

Copy link
Collaborator

@Nadrieril Nadrieril commented Mar 11, 2020

Do we expect { x.y.z } to parse ? It could be read as either { x.y.z = x.y.z } or { x.y.z = z } but neither feels very natural

@jvanbruegge

This comment has been minimized.

Copy link

@jvanbruegge jvanbruegge commented Mar 11, 2020

I would expect the former
Or forbit it

@sjakobi

This comment has been minimized.

Copy link
Collaborator

@sjakobi sjakobi commented Mar 11, 2020

Following the existing desugaring logic I'd expect { x.y.z } to expand to { x = { y = { z } } }, i.e. { x.y.z = z }. But it's not very obvious, and it mixes two kinds of sugar, so I'd expect it to cause some confusion at least.

My inclination would be not to standardize this syntax for now.

Nadrieril added a commit to Nadrieril/dhall-lang that referenced this issue Mar 11, 2020
Nadrieril added a commit to Nadrieril/dhall-lang that referenced this issue Mar 11, 2020
@sjakobi

This comment has been minimized.

Copy link
Collaborator

@sjakobi sjakobi commented Mar 11, 2020

In principle we could also consider supporting puns in with-expressions, e.g.

record with x

…as a shortcut for

record with x = x

But as long as we don't allow puns for nested fields (e.g. { x.y } or, in this case, record with x.y), I don't expect that anyone would want to use that.

Nadrieril added a commit that referenced this issue Mar 14, 2020
* Tweak `with` grammar for generated parsers

* Standardize record puns (#867)

* Add a test for mixing record sugars

As suggested by @sjakobi
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

7 participants
You can’t perform that action at this time.