Add var <type> <identifier> [ = <value> ]; syntax for variables
#339
Conversation
|
Proposal links (add links as proposal evolves):
|
jonmeow
added
proposal rfc
| code: | ||
|
|
||
| 1. What is the type of variable `x`? | ||
| 2. What is the identifier of the `Int` variable? |
There was a problem hiding this comment.
Also, "where is x declared?" I know it was not a part of the quoted study, but I think it is a question that I ask myself often when reading code.
There was a problem hiding this comment.
Thank you for the feedback, but I really intended this section to focus on the mirroring of these two questions, and while your suggestion is related I think it's both required to answer either question and would also detract from the contrast.
proposals/p0339.md
Outdated
| for type syntax to be more flexible because it can rely on a following syntax | ||
| element to disambiguate breaks. However, type syntax may be constrained | ||
| sufficiently regardless of `:`. This implies the presence of `:` would mostly be | ||
| to address _visual_ ambiguity, not _compiler_ ambiguity. |
There was a problem hiding this comment.
Have you tried out removing the colon from the parser?
You suggest that while it might be ambiguous now, that some other changes might make it unambiguous.
Without suggesting those other changes, this would put us in a messy situation.
There was a problem hiding this comment.
I gave it a try... removing the colon introduces some shift/reduce conflicts, but that is a mild form of ambiguity. There were no reduce/reduce conflicts, which are the deadly ones. I did not test on all the examples, though I did check one. So my guess is that removing the colon probably is OK from a parsing perspective.
There was a problem hiding this comment.
Thanks, good to hear.
I would note though, it may just mean that we'd need to go in a different path. In particular, the most issues I'd expect are from syntax like VAR pattern "=" expression ";" -- but I'm not sure whether pattern is the right level of expressivity there (note, this may be my own lack of foresight into the issues).
Co-authored-by: Geoff Romer <[email protected]>
Co-authored-by: austern <[email protected]>
…arbon-lang into proposal-var-statement
jonmeow
changed the title
var statementvar <type> <identifier> [ = <value> ]; syntax for variables
jonmeow
changed the title
var <type> <identifier> [ = <value> ]; syntax for variablesvar <type> <identifier> [ = <value> ]; syntax for variables
Following the rules proposed in #339.
github-actions
bot
added
proposal accepted
Starting to apply #339 Co-authored-by: Richard Smith <[email protected]>
Propose the decision from #542, noting implementation from #563 Also integrates some of #339 into `variables.md` because that's actually how this started, looking for a proposal reference for #542 Co-authored-by: Richard Smith <[email protected]> Co-authored-by: josh11b <[email protected]>
Following the rules proposed in #339.
Co-authored-by: Geoff Romer <[email protected]> Co-authored-by: austern <[email protected]>
Starting to apply #339 Co-authored-by: Richard Smith <[email protected]>
Propose the decision from #542, noting implementation from #563 Also integrates some of #339 into `variables.md` because that's actually how this started, looking for a proposal reference for #542 Co-authored-by: Richard Smith <[email protected]> Co-authored-by: josh11b <[email protected]>
Adopt
var <type> <identifier> [ = <value> ];syntax for variables