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

Fix deltaparsing #1197

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from
Draft

Fix deltaparsing #1197

wants to merge 10 commits into from

Conversation

larskuhtz
Copy link
Contributor

Goal of this PR is not necessarily to deploy a fix for deltas in the production parser. The goal is to document the current and correct behaviors and provide implementations for correct and legacy behavior. This will help to explore the current state of affairs and future fixes.


moduleState :: Compile ModuleState
moduleState = use (psUser . csModule) >>= \m -> case m of
moduleState = use (psUser . csModule) >>= \case
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is doing so much more than fixing delta-parsing. Can you submit all of these minor cleanups in their own PR first? That way we can trivially approve and merge those, and then think harder about just the Delta parsing fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can, it just is quite a bit of extra work to create new PR each time I fix syntax. There are just so many of those syntactic inconsistencies that make readability of the code unnecessarily hard. Fixing them from time to time along the way is just easier.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case a LOT of the changes are just fixing syntax, so then it makes sense to bundle all of that up into a PR before making an important change like delta parsing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1197

(The issue is that I don't first read the the whole code base and clean it up and then start working on the feature, but those changes are interleaved with other changes in the PR. For instance, above PR caused merge conflicts during the cherry pick and now I have to wait for it to be squash merged into master before I can merge it back into the original PR, which again will require to resolve the conflict.)

@larskuhtz larskuhtz mentioned this pull request Apr 19, 2023
larskuhtz and others added 3 commits April 19, 2023 00:04
* tweaks to deltaparser

* Update tests/GasModelSpec.hs

---------

Co-authored-by: Lars Kuhtz <lars@kadena.io>
@@ -47,7 +47,7 @@ flag tests-in-lib
manual: True

library

cpp-options: -DLEGACY_PARSER=1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple thoughts

You don't need to set =1 for binary flags, you can just define -DLEGACY_PARSER.
Then CPP if-blocks become like

#ifdef LEGACY_PARSER
...
#else
...
#endif

or

#if someCondition
...
#elifdef LEGACY_PARSER
...
#endif

The other thought is that it could be behind a flag:

flag legacy-parser
  description: ...
  default: True
  manual: True
  
library
  if flag(legacy-parser)
    cpp-options: -DLEGACY_PARSER

Which would make toggling it on/off not require editing the cabal file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, this is all temporary for now. I tried to define the macro in cabal.project.local but cabal doesn't like that, so I had to put it into the cabal file.

Regarding using 1/0, sometimes I like to be more explicit when dealing with macros (I find it easy to mess up with #define and #undef). Yeah, if that macro would still be in the final version of the code, we would use a standard pattern with (automatic) cabal flag. But, hopefully, that won't be necessary.

-- hidden chars like Trifecta).
--
instance DeltaParsing PactAttoparsec where
line = return mempty
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about something like this:

Suggested change
line = return mempty
line = PactAttoparsec (fail "DeltaParsing.line is not supported for PactAttoparsec")

The error message is more informative, than giving an empty string.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assuming it's actually not used ...

{-# INLINE position #-}

slicedWith f a = (`f` mempty) <$> a
rend = return mempty
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to line, I think rend and restOfLine, if not used, should return informative error messages

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

Successfully merging this pull request may close these issues.

4 participants