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

WIP: Make Ident a Functor #90

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

WIP: Make Ident a Functor #90

wants to merge 7 commits into from

Conversation

kalhauge
Copy link

Hi all,

Thanks for all the hard work you put into this package.
I was currently working on a project that produced C files, and I want to test that the Ast I create can be read again. However with the current setup it is very hard to compare two AST's.

This is only meant for inspiration, and should not be merged as is.

What I have done:

  • Made Ident a functor
  • Created data types for all tuples used in the AST (which made the AST not able to derive Functor)
  • Made the AST able to check if it is equal with another AST.

I needed to make Ident a functor so that I could errase
all annotations. This, however, had some side-effects that
made refactor the AST in a breaking way. But now it is possible
to derive 'functor' for all objects in the AST.

The main changes are in `src/Language/C/Syntax/AST.hs`

instance NFData Ident
instance NFData a => NFData (Identifier a)

-- the definition of the equality allows identifiers to be equal that are
-- defined at different source text positions, and aims at speeding up the
-- equality test, by comparing the lexemes only if the two numbers are equal
--
Copy link
Collaborator

Choose a reason for hiding this comment

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

I wonder if being polymorphic over the NodeInfo it would be worth removing the weirdy Eq/Ord instance. One could always do something like (==) `on` void to regain the old behavior.

Copy link
Author

Choose a reason for hiding this comment

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

Yes! great catch! I think it would make sense to stay with the stock implementations.

@expipiplus1
Copy link
Collaborator

Thanks! I'm all for this. What's left to do before dropping the WIP flag?

@kalhauge
Copy link
Author

kalhauge commented Oct 3, 2022

Thanks! I'm all for this. What's left to do before dropping the WIP flag?

Happy you like it :). The primary reason it is WIP is because I did not know if it was in the spirit of the repository, but now that you approve with the direction I think that what is missing, considering this is a already a breaking change, is:

  • Add documentation for the newly added data types,
  • Make sure the tests are succeeding,

Further more, I think that we could improve the code a little by, but that might fit better in another pull request:

  • Be consistent with the use of Generic1,
  • Maybe let Annotated be generated using Generic,
  • CNode is now just nodeInfo = annotation for all classes,
  • Pos is always posOf = posOf . nodeInfo, and finally
  • CDeclarationItem Seems to only have four valid 'states', however the current (Maybe a) (Maybe b) (Maybe c) pattern allows for 8 'states'. Maybe making those 'states' explicit might make the code easier to read (I have started with the CDeclI pattern).

@Bodigrim Bodigrim force-pushed the master branch 2 times, most recently from 8ac47c2 to adc8883 Compare November 12, 2024 23:54
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.

2 participants