Updates for v0.28.0 #55
Conversation
|
I wanted to update on the status of this PR. Currently it's failing the integrations suite, because some of the code therein isn't Gleam v0.28.0 compliant. There are (at least) three roads forward:
Feedback here welcome 😁 |
|
I was curious about that with some of the changes from 0.30 like removing the 'external' from external types. I think it would be ok to be more permissive about deprecated / removed syntaxes. We could have some policy like keeping around old syntaxes for a few versions and eventually dropping them, since maintaining deprecated code forever is a big pain. For the integration tests though I think we could also limit the set of repos to those that are usually up-to-date soon after syntax changes, just to minimize the maintenance burden. |
|
Agreed! Keeping them around for at least long enough for the community to largely have moved over would be good. Currently Gleam supports both syntaxes, and I think it'd make sense for tooling to support both for longer still. |
This makes me a little uneasy, as the way that the Gleam parser parses
"let assert" is that it first parses "let", then calls
"parse_assignment" which will look to see if an "assert" comes next,
and uses this information to choose the node type.
I think a closer tree-sitter implementation would look like this:
_statement: ($) => choice($._expression, $._assignment, $.use),
...
_assignment: ($) => choice($.let, $.let_assert),
let: ($) => seq("let", $._assignment2),
let_assert: ($) => seq("let", "assert", $._assignment2)
_assignment2: ($) =>
...
However this requires an awkward "_assignment2" and isn't
substantially closer to the Gleam parser to warrant the change.
Also we could simply do `optional("assert")`, but that would make
"let" and "let assert" the same node type, which I suspect is an anti-feature.
Co-authored-by: Michael Davis <[email protected]>
There's a lot here, but then again a lot changed!
Each commit is a self-contained unit, please view them individually to retain your sanity 😁