Rename lexer and parser to prevent conflicts #54
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Within erlex, the lexer and parser are generically named as
:lexer
and:parser
. This generic naming has led to conflicts with other libraries that employ:lexer
and:parser
modules in their own implementations.A particular example of such a conflict is the clash with the lexer and parser in the SPARQL.ex library. This issue came to my attention after extensive troubleshooting, highlighting the difficulty in diagnosing such conflicts.
Historically, in older versions of Elixir, the SPARQL lexer and parser seemed to be preferentially loaded, which led to concealed issues when using dialyxir. These issues typically manifested as legacy warnings, triggered by the unsuccessful use of the SPARQL parser in parsing Dialyzer data. Given that legacy warnings are also commonly produced for unsupported formats (notably, dialyxir currently has 74 issues related to legacy warnings), this underlying conflict between parsers remained unrecognized for a considerable duration.
The conflict became evident with recent changes in the compilation process introduced in Elixir 1.15. These modifications in module loading behavior brought the previously unnoticed conflict to light, where the erlex parser was unexpectedly employed in parsing SPARQL queries. Intriguingly, this issue did not arise consistently but only manifested from the second attempt after a recompilation and was still not immediately recognizable as a parser conflict, since the parser errors were translated to regular SPARQL.ex parser errors.
Although I have already addressed this issue in SPARQL.ex by adopting more unique names for the lexer and parser, I believe that a similar resolution should be implemented in erlex. Considering its widespread use, primarily as a transitive dependency of dialyxir, many projects may unknowingly be at risk of similar conflicts.