declareHasChunkRefs: Generate instances of HasChunkRefs where possible#4476
Merged
JacquesCarette merged 10 commits intomainfrom Dec 11, 2025
Merged
declareHasChunkRefs: Generate instances of HasChunkRefs where possible#4476JacquesCarette merged 10 commits intomainfrom
declareHasChunkRefs: Generate instances of HasChunkRefs where possible#4476JacquesCarette merged 10 commits intomainfrom
Conversation
HasChunkRefs; declareChunkTypeHasChunkRefs; declareHasChunkRefs
HasChunkRefs; declareHasChunkRefsdeclareHasChunkRefs: Generate instances of HasChunkRefs where possible
Collaborator
Author
|
Pausing work on this until #4489 has resolved. |
Reed suggested (and assisted in implementing) using 'deriving-via' rather than 'deriving-anyclass' as the strategy for sharing the default implementation of `HasChunkRefs`. Co-Authored-By: Reed Mullanix <reedmullanix@gmail.com>
388c0a3 to
07f54c9
Compare
Collaborator
Author
|
Latest force-push is for rebasing atop |
Collaborator
Author
|
We should be able to remove https://github.com/JacquesCarette/Drasil/blob/main/code/drasil-printers/lib/Language/Drasil/Debug/Print.hs in favour of a more generic approach similar to the one we take in this PR. |
Merged
Owner
|
#4489 is now merged, so I guess work on this can re-start? |
Owner
|
Since @Xinlu-Y has based 2 PRs on top of this one (indirectly), it becomes important that this gets resolved sooner rather than later. |
DeriveGeneric, and StandaloneDeriving.
`UID`s are meant to be *owned*!
declareHasChunkRefs: Generate instances of HasChunkRefs where possibledeclareHasChunkRefs: Generate instances of HasChunkRefs where possible
balacij
commented
Dec 11, 2025
Collaborator
Author
There was a problem hiding this comment.
- Once we convert external usage of
UIDtoTypedUIDRef(excluding the times where aUIDshould actually indicate theUIDof a chunk carrying saidUID), we can also usederiveHasChunkRefson our 'chunk atoms.' Furthermore, when this is done, we can also generateHasUID. Future work! - After this PR, we can slowly convert the
instance hasChunkRefswe currently have on our chunk types todeclareHasChunkRefs(which I believe @Xinlu-Y wants to work on?).
For now, I'm content with this PR's scope.
Ready for review @JacquesCarette @Xinlu-Y ! Thank you!
JacquesCarette
approved these changes
Dec 11, 2025
This file contains hidden or 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
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.
Contributes to #4434 and #4349
A
Chunk(in the code) is defined by the following constraint:Currently, none of our
HasChunkRefsinstances are meaningfully filled in (#4349). The goal of #4434 is to fill them in. The goal of this PR is to assist with #4434 by "automating the boring stuff." #4434 commonly contains code of the following form:This PR introduces a bit of Generics- and TH-based automation to derive these 'boring' instances, for example those that merely take the
unionof the various atoms within a chunk.