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

Fix inline record printing in outcome printer #2336

Conversation

anmonteiro
Copy link
Member

This fixes #1163 and supersedes #2103

@@ -0,0 +1,6 @@
type t0 = T0 { t0: int, };
type t1 = A { x: int, } | B | C { c1: string, c2: string, };
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't Reason have parens around constructor args?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. Here's an rtop session:

Reason # type a = | A {x:int}: a;
type a = A(): a;
Reason # type a = | A {x:int};
type a = A();
Reason # type a = | A({x:int});;
Error: Syntax error
Reason # type a = | A {x:int}: a;
type a = A(): a;
Reason # type a = | A ({x:int}): a;
Error: Syntax error

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it should, though?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The lack of support for wrapping parens for inline records, when they're required in other cases, is very confusing. It's an inconsistency which would be good to fix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I just saw someone get pretty confused about this too.
One somewhat related question I have is if there might ever be a change in OCaml that requires syntactically distinguishing values of inline variant records vs. values of variants that happen to contain records as their payload. I doubt it. That tells me that we should probably move to consistent parens everywhere.
If we hypothetically one day figured out a way to be able to drop parens for single argument things, then we would apply it consistently everywhere, not just on variants. Good discussion, thanks.

@anmonteiro anmonteiro force-pushed the anmonteiro/print-inline-record-constructors branch from 70d1c02 to 6eb0525 Compare March 30, 2019 10:59
@anmonteiro
Copy link
Member Author

@jordwalke rebased on master.

@anmonteiro anmonteiro force-pushed the anmonteiro/print-inline-record-constructors branch from 6eb0525 to f046548 Compare March 31, 2019 10:38
type t0 = T0 { t0: int, };
type t1 = A { x: int, } | B | C { c1: string, c2: string, };
type t2(_) =
D { x: int, }: t2(int)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! You have a GADT test case.

@@ -0,0 +1,6 @@
type t0 = T0 { t0: int, };
type t1 = A { x: int, } | B | C { c1: string, c2: string, };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I just saw someone get pretty confused about this too.
One somewhat related question I have is if there might ever be a change in OCaml that requires syntactically distinguishing values of inline variant records vs. values of variants that happen to contain records as their payload. I doubt it. That tells me that we should probably move to consistent parens everywhere.
If we hypothetically one day figured out a way to be able to drop parens for single argument things, then we would apply it consistently everywhere, not just on variants. Good discussion, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inline records in variant type definitions aren't pretty-printed properly in rtop
5 participants