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

Refactor .cfg file processing #159

Open
haxscramper opened this issue Jan 16, 2022 · 0 comments
Open

Refactor .cfg file processing #159

haxscramper opened this issue Jan 16, 2022 · 0 comments
Labels
good first issue Easy-to-start-with issue with no in-depth knowledge or complex implementation required. refactor Implementation refactor

Comments

@haxscramper
Copy link
Collaborator

haxscramper commented Jan 16, 2022

The current implementation of the .cfg file processing does not have any form of AST and instead evaluates code directly during lexing, mutating the global configuration values in-place. Refactoring the .cfg file parser would allow:

  • make testing simpler - instead of mutating whole global configuration in-place, test can be separated into parser (can test and assert structure of the AST) and evaluation (can properly assert changed values).

  • Together with Refactor active configuration handling #158 .cfg parser can now be seen as a simple function of the input (config: string, oldOptions: ActiveOptions) -> ActiveOptions

  • std/parsecfg can be used in regular code, but the compiler has nonstandard implementation that cannot be used or understood by external tooling, requiring full reimplementation. Having proper AST will address this issue at least as far as reading is concerned

  • Compiler implementation uses nim lexer to "save space and work", which causes more syntax discrepancies: path=$config/test is valid in one syntax, but for .cfg you need to use `path="$config/test" only

  • Testament uses parsecfg with support for ''' for multiline string literals implemented via s.substr(a, b-1).multiReplace({"'''": tripleQuote, "\\31": "\31"})

  • Changes can be made either by improving the current std/parsecfg parser to include events for @if, @command etc., or rewriting the current nimconf.nim to use the implementation from parsecfg - in that case new module can be added into experimental/parsecfg and used only for compiler needs for the time being.

@haxscramper haxscramper added good first issue Easy-to-start-with issue with no in-depth knowledge or complex implementation required. refactor Implementation refactor labels Jan 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Easy-to-start-with issue with no in-depth knowledge or complex implementation required. refactor Implementation refactor
Projects
Development

No branches or pull requests

1 participant