1494 parse dol standard examples #2154
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's no longer part of the standard, so there's no need to parse it anymore. 'library' is sufficient.
See the comments in the file for an explanation. In short: those parts make the parser choke, but not because of DOL related problems. So they have to go until those unrelated problems have been fixed.
It's not part of the DOL grammar and that's how it should be as it's also not part of the alignment API.
The DOL Standard doesn't allow those. Should be plain text keywords instead.
The standard says they should simply be doubles, not enclosed in parentheses.
If the `= ...` part is omitted it now defaults to the empty specification/oms/network.
It's a minuscule change but that way, it stays in line with how the rest of Hets is organized.
Don't know whether that's the correct way, but it's my stab at getting `OMS Extraction` to work. From what I gathered by reading the code this should be the right way to do it.
For some reason Hets leaves the angular brackets in there, when parsing IRIs at least in this small code sample. This prevents logic lookup from working properly. I opted for this short hack, as it I don't know whether other code relies on the brackets being there and removing them just before looking up the logic is the option that is least likely to break other code.
Since only one function is used in the importing module, I'd like to make that explicit.
Logic `OWL`, sublogic `NP-sROIQ-D|-|` should be correct but Hets errors out saying it doesn't know the logic `NP-sROIQ-D|-|`. For now simply using `OWL` seems to work, but it's a hack that should be corrected at some point.
Same (maybe) problem as in `lookupLogicName`. The IRI passed in as a parameter is still enclosed in angular brackets which is not expected by those functions. Filtering the brackets might only address the symptom of a bigger issue but it fixes the problem at hand and has the least effects on the remaining codebase.
This reverts commit 17aa52c and instead applies the fix closer to logic name lookup inside the function doing the lookup. That way both fixes for serialization and logic name lookup (which are identical) are grouped in one file.
As the comments says, theres a proper way to do it by using the information stored in the `LanguageQual` that is the result of parsing the `language` declaration. But this would entail expanding a possible prefix of the `LanguageQual` and I don't have time to implement this right now. I'll open an issue for this so that I can work on it later. For now, parsing the DOL examples is more important so I added this hack to get an intermediate working solution.
Now it also adds support for more logics/languages and various translations.
Thanks @cmaeder for the suggestion. Using `spaces` has two benefits. It gets rid of a dependency issue resulting in a compilation error and it allows me to be consistent and only eat up whitespace at the end of lines.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
see also discussion in #1540