[Nix#8613] Make sure we can fix the parser's bad list/number interactions #135

Open
opened 2024-03-16 06:45:06 +00:00 by lix-bot · 0 comments
Member

Upstream-Issue: NixOS/nix#8613

Is your feature request related to a problem? Please describe.

We have to obscure syntaxes that can be argued to be bugs; certainly one of them.
However, changing the tokenizer/parser for them technically means breaking the language.

  • #8605
    • [ 01.1 ] == [ 1 0.1 ]
  • #7695
    • [ 0xff ] == [ 0 xff ] if xff is in scope

I think bug for bug compatibility is valuable, but also costly. In this case the cost/benefit of bug for bug compatibility seems off, and we may have a way out.

Describe the solution you'd like

Language versioning would be great, but going this route also means that we'd have to indefinitely support the bad syntax.
So regardless of the language versioning idea, we can run an experiment to verify that the community does not rely on the bad syntax, and then "break" the syntax to no ill effect.
Benefits:

  • clean up the implementation; less maintenance overhead
  • the default language version has better syntax

Method:

  • reject the bad syntaxes in the lexer and/or parser. Ask users to open an issue in the error message.
  • wait
  • if nothing is reported, fix and improve the lexer and/or parser as appropriate depending on whether an issue was created

Describe alternatives you've considered

Wait for language versioning and maintain the bad syntax forever even if there's no benefit of doing so.

Additional context

Priorities

Add 👍 to issues you find important.

Upstream-Issue: https://git.lix.systems/NixOS/nix/issues/8613 **Is your feature request related to a problem? Please describe.** We have to obscure syntaxes that can be argued to be bugs; certainly one of them. However, changing the tokenizer/parser for them technically means breaking the language. - #8605 - `[ 01.1 ] == [ 1 0.1 ]` - #7695 - `[ 0xff ] == [ 0 xff ]` if `xff` is in scope I think bug for bug compatibility is valuable, but also costly. In this case the cost/benefit of bug for bug compatibility seems off, and we may have a way out. **Describe the solution you'd like** Language versioning would be great, but going this route also means that we'd have to indefinitely support the bad syntax. So regardless of the language versioning idea, we can run an experiment to verify that the community does not rely on the bad syntax, and then "break" the syntax to no ill effect. Benefits: - clean up the implementation; less maintenance overhead - the default language version has better syntax Method: - reject the bad syntaxes in the lexer and/or parser. Ask users to open an issue in the error message. - wait - if nothing is reported, fix and improve the lexer and/or parser as appropriate depending on whether an issue was created **Describe alternatives you've considered** Wait for language versioning and maintain the bad syntax forever even if there's no benefit of doing so. **Additional context** **Priorities** Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).
lix-bot added the
bug
imported
labels 2024-03-16 06:45:06 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#135
No description provided.