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

Javacc4 config input file #259

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

Henne
Copy link

@Henne Henne commented Mar 20, 2019

This patchset applies the code from Configuration.java to the input file config.jj which is used to generate a fresh parser.
Only config.jj is changed in this patchset, so nothing can break.

A generated parser by JavaCC V4.0 from this config.jj has still differences to the currently used code,
but they are either trivial or unmodifiable by editing config.jj.

This is the diffstat of a patch from the current Configuration.java to a fresh one from JavaCC 4.0:

Configuration.java | 95 +++++++++++++++++++++--------------------------------
1 file changed, 38 insertions(+), 57 deletions(-)

Best regards.

P.S.: I fully understand and agree with your arguments and I'm not discouraged by your rejection.
Also I understand that my initial pull request #248 was too ambitious and could have been made more comprehensible.

Sadly I could not reproduce the failed JUnit-Tests you mentioned in #254, since I ran them also on my machine where they did not fail. I'm using:
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.18.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

Henrik Kretzschmar added 6 commits March 20, 2019 07:54
Rename the package names from tlatk to tla2sany and
import the packages like they are imported in the file
tlatools/src/tla2sany/Configuration.java.

Note: When generating a parser from config.jj these imports are
copied to the two files Configuration.java and ConfigurationTokenManager.java.
The package name will be copied to all 7 files.

This changes are non-functional.

[Refactor][SANY]
Insert the code from Configuration.java into config.jj.

* insert two static members errors and input
* update the load() method
* indent the load() and displayDefinitions() by two whitespaces

Note: When generating a parser from config.jj this code will be
copied to Configuration.java.

This changes are non-functional.

[Refactor][SANY]
Add throws AbortException to three methods that also have it in
Configuration.java.

Note: When generating a parser from config.jj the code for that
methods is generated and inserted into Configuration.java

This patch is non-functional.

[Refactor][SANY]
Update the actions of the OpBuiltin() method,
which represents the non-terminal OpBuiltin,
that they match the method of the same name in Configuration.java.

This patch is non-functional.

[Refactor][SANY]
These changes let the output of the generated code be
indented the same way it is currently in Configuration.java.

These changes are non-functional.

[Refactor][SANY]
JavaCC can generate code for different source levels.
TLATools uses "1.8" at the moment.

These changes are non-functional.

[Refactor][SANY]
@lemmy

This comment was marked as off-topic.

@Henne

This comment was marked as off-topic.

@lemmy

This comment was marked as off-topic.

@lemmy

This comment was marked as off-topic.

@lemmy
Copy link
Member

lemmy commented Dec 18, 2019

#408 would be a good reason to continue work on this PR.

@ahelwer
Copy link
Contributor

ahelwer commented Mar 18, 2024

Upon investigation the entire purpose of this parser is just to parse a large string encoding all the operator symbols of TLA+ and their precedence ranges, associativity, etc. during SANY initialization (see tlatools/src/tla2sany/configuration/ConfigConstants.java). It does not have anything to do with parsing the TLC configuration file as I originally believed (I actually independently created nearly this exact changeset because I didn't know about this PR). It is my opinion that this entire configuration parser should be torn out in favor of just defining a series of Operator objects directly, and therefore this PR should be closed. Ref #891

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants