You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Playground has some linting abilities (diagnostics on WARN level), such as unused imports and deprecated features. Historically, these have been implemented as part of the QueryCompilerVisitor, which traverses the input type schema and returns roughly an AST => Ior[Diagnostics, Decoded].
This has several problems:
Coupling
Self-explanatory: the linting abilities are coupled to compilation, and adding more will pollute the compiler code, which is arguably the most important piece of the whole project.
Ior composition
This one is more subtle: non-successful Iors never compose RHS with successful ones. This requires extra care in things like parTraverses, as well as |+| and similar.
Additionally, we have seal, which turns any ERROR diagnostics in an Ior into a failed Ior.
Ior is used so that we can produce non-fatal diagnostics together with a successful result, and splitting up the compiler into two separate components would remove the need for it. In addition, seal would be redundant because every compiler diagnostic would be an error.
Given the reasons above, it's at least worth an experiment: extract a linting visitor and remove the remaining linting abilities from the compiler.
The effects of the visitors should look a little like:
compiler: AST => Either[Nel[Diagnostic], A]
linter: AST => List[Diagnostic]
The text was updated successfully, but these errors were encountered:
Playground has some linting abilities (diagnostics on WARN level), such as unused imports and deprecated features. Historically, these have been implemented as part of the
QueryCompilerVisitor
, which traverses the input type schema and returns roughly anAST => Ior[Diagnostics, Decoded]
.This has several problems:
Coupling
Self-explanatory: the linting abilities are coupled to compilation, and adding more will pollute the compiler code, which is arguably the most important piece of the whole project.
Ior composition
This one is more subtle: non-successful
Ior
s never compose RHS with successful ones. This requires extra care in things likeparTraverse
s, as well as|+|
and similar.Additionally, we have
seal
, which turns anyERROR
diagnostics in anIor
into a failedIor
.Ior
is used so that we can produce non-fatal diagnostics together with a successful result, and splitting up the compiler into two separate components would remove the need for it. In addition,seal
would be redundant because every compiler diagnostic would be an error.Given the reasons above, it's at least worth an experiment: extract a linting visitor and remove the remaining linting abilities from the compiler.
The effects of the visitors should look a little like:
AST => Either[Nel[Diagnostic], A]
AST => List[Diagnostic]
The text was updated successfully, but these errors were encountered: