Reason V4 [Stack 3/n] [Parse Hashtags for polymorphic variants] #2614
Conversation
|
I guess polyvars for colors isn't particularly a good fit, |
| @@ -0,0 +1,97 @@ | |||
| (** | |||
There was a problem hiding this comment.
Looks like this comment is a duplicate of the one in the interface, I understand why you might want to have it here though, this can probably be not a doc comment
There was a problem hiding this comment.
This diff is actually tiny, but on top of a rebase of two other PRs unmerged. The one you are discussing is actually here. Would you mind commenting on the specific PR if you have feedback?
I will likely be aggressively rebasing and force pushing to all of these PRs to keep them clean and comprehensible, where each PR's top commit is the real change for that PR with the underlying commits on the PR being other PRs.
|
@jordwalke @flash-gordon maybe we can accept poly variants starting with numbers? It's going to be really useful on a BS context. |
Why do you have to ruin my demo :D j/k But yes, you are correct. I suppose there's nothing preventing us from actually forcing those identifiers to be valid in the parse tree. This diff doesn't implement that feature and I wasn't planning on implementing it but in theory it's possible. (The problem is making it interoperate with OCaml). |
|
@EduardoRFS what do you mean exactly? Do you mean Imagine the horrendous type: I don't think OCaml would allow a type definition with that size. A better solution may be a syntactic shortcut, that lets you implicitly pair colors together into a 3-tuple |
|
@jordwalke sorry not even I know what I intended on that comment, but the point is, why not allow poly variants starting with numbers? The AST clearly supports it, and probably the compiler also supports it(I would be surprised otherwise). It's same kinda of change as we did on |
|
@EduardoRFS Yeah that's a good point. We very well could parse those identifiers. The main downside is that then we would be able to define APIs that OCaml cannot call. That is probably something to be minimized - or at the very least, there should be a large benefit to being able to define those kinds of APIs, and I think that if colors could be expressed practically, that would be one such benefit, but I cannot imagine how to make the types comprehensible. We may prefer to go another route for type safe hex colors. There may be enough syntactic real estate for postfix hashtag |
|
Oh that's a good point, you will not be able to check it on the type system unless you make a variant with all colors, which is a terrible idea and no one should do it. |
|
In ocaml we can have |
jordwalke
force-pushed
the
HashTags
branch
2 times, most recently
from
b6ac0aa
to
54fafb2
Compare
…riants]
Summary:
Implements parsing for "hashtags" polymorphic variant constructors.
Since Reason Syntax still supports object syntax, we needed to rearrange
some syntactic real estate to make this work.
```reason
let red = #FF000;
let isRed = color => switch(color) {
| #FF0000 => true
| _ => false
};
let callAMethod = someObject::methodName(isRed, "testing red");
let templateLiteral = `
String template literals are still using backticks.
String template literals are still using backticks.
`;
```
Test Plan:
Reviewers:
CC:
jordwalke
changed the title
jordwalke
changed the title
…riants]
Summary:
Implements parsing for "hashtags" polymorphic variant constructors.
Since Reason Syntax still supports object syntax, we needed to rearrange
some syntactic real estate to make this work.
```reason
let red = #FF000;
let isRed = color => switch(color) {
| #FF0000 => true
| _ => false
};
let callAMethod = someObject::methodName(isRed, "testing red");
let templateLiteral = `
String template literals are still using backticks.
String template literals are still using backticks.
`;
```
Test Plan:
Reviewers:
CC:
…riants]
Summary:
Implements parsing for "hashtags" polymorphic variant constructors.
Since Reason Syntax still supports object syntax, we needed to rearrange
some syntactic real estate to make this work.
```reason
let red = #FF000;
let isRed = color => switch(color) {
| #FF0000 => true
| _ => false
};
let callAMethod = someObject::methodName(isRed, "testing red");
let templateLiteral = `
String template literals are still using backticks.
String template literals are still using backticks.
`;
```
Test Plan:
Reviewers:
CC:
…riants]
Summary:
Implements parsing for "hashtags" polymorphic variant constructors.
Since Reason Syntax still supports object syntax, we needed to rearrange
some syntactic real estate to make this work.
```reason
let red = #FF000;
let isRed = color => switch(color) {
| #FF0000 => true
| _ => false
};
let callAMethod = someObject::methodName(isRed, "testing red");
let templateLiteral = `
String template literals are still using backticks.
String template literals are still using backticks.
`;
```
Test Plan:
Reviewers:
CC:
…riants]
Summary:
Implements parsing for "hashtags" polymorphic variant constructors.
Since Reason Syntax still supports object syntax, we needed to rearrange
some syntactic real estate to make this work.
```reason
let red = #FF000;
let isRed = color => switch(color) {
| #FF0000 => true
| _ => false
};
let callAMethod = someObject::methodName(isRed, "testing red");
let templateLiteral = `
String template literals are still using backticks.
String template literals are still using backticks.
`;
```
Test Plan:
Reviewers:
CC:
…riants]
Summary:
Implements parsing for "hashtags" polymorphic variant constructors.
Since Reason Syntax still supports object syntax, we needed to rearrange
some syntactic real estate to make this work.
```reason
let red = #FF000;
let isRed = color => switch(color) {
| #FF0000 => true
| _ => false
};
let callAMethod = someObject::methodName(isRed, "testing red");
let templateLiteral = `
String template literals are still using backticks.
String template literals are still using backticks.
`;
```
Test Plan:
Reviewers:
CC:
…riants]
Summary:
Implements parsing for "hashtags" polymorphic variant constructors.
Since Reason Syntax still supports object syntax, we needed to rearrange
some syntactic real estate to make this work.
```reason
let red = #FF000;
let isRed = color => switch(color) {
| #FF0000 => true
| _ => false
};
let callAMethod = someObject::methodName(isRed, "testing red");
let templateLiteral = `
String template literals are still using backticks.
String template literals are still using backticks.
`;
```
Test Plan:
Reviewers:
CC:
…riants]
Summary:
Implements parsing for "hashtags" polymorphic variant constructors.
Since Reason Syntax still supports object syntax, we needed to rearrange
some syntactic real estate to make this work.
```reason
let red = #FF000;
let isRed = color => switch(color) {
| #FF0000 => true
| _ => false
};
let callAMethod = someObject::methodName(isRed, "testing red");
let templateLiteral = `
String template literals are still using backticks.
String template literals are still using backticks.
`;
```
Test Plan:
Reviewers:
CC:
This reverts commit f005630051aa47c2e2a51634229e8f26d7b56ab6.
This reverts commit f005630051aa47c2e2a51634229e8f26d7b56ab6.
Summary:This allows multiple versions of Reason in a single project by inferring and recording the version of syntax used into the file in an attribute. The attribute allows us to switch the parser and lexer on the fly. This attribute is not the only way we can infer the version, and we can allow project level configuration, but this is the approach that is guaranteed to work with any build system or tooling. Test Plan: Reviewers: CC:
Summary:This diff implements string template literals. Test Plan: Reviewers: CC:
This reverts commit f005630051aa47c2e2a51634229e8f26d7b56ab6.
|
ocaml/ocaml#9429 Possible problem |
Reason v4 - Parse Hashtags for polymorphic variants.
Implements parsing for "hashtags" polymorphic variant constructors.
Since Reason Syntax still supports object syntax, we needed to rearrange
some syntactic real estate to make this work.
Update:
I also added a cool new feature for upgrading to this diff. Even if you have not upgraded your file to the new syntax, it will detect if you use some new syntax features in the old syntax, and then use that as a hint to automatically upgrade your file (and annotate it with the new version marker)
So if you have:
Then the usage of
list<int>will have refmt intelligently detect that you are trying to use a new feature, and it will automatically upgrade the entire file next time you reformat in-editor. It will print your file as:The way this works is by having the parser be able to parse some v4 features inside of v3 (the ones that don't conflict) and detect when you use them.
So the per-file upgrade process is now: