Internal refactoring: Use "trees that grow" for BriDoc #50
Labels
No Label
blocked: dependency
blocked: info-needed
bug
duplicate
enhancement
fixed in HEAD
help wanted
hs:arrows
hs:brackets
hs:classes
hs:comments
hs:do-notation
hs:guards
hs:lists
hs:operators
hs:patterns
hs:records
hs:types
invalid
language extension support
layouting
needs confirmation
priority: high
priority: low
question
revisit before next release
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: hexagoxel/brittany#50
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
See Trees that Grow paper by Najd, Jones.
This approach can merge
BriDocFInt
andBriDoc
without adding anyby adding minimal (source-text) overhead in any functions that use these types. (There will be some overhead in the representation of BriDoc nodes, but I don't think that general performance will suffer much.)Unfortunately syb/uniplate are not very compatible with this approach, as far as I can see. E.g. we would not be able to use uniplate in its current form to express a transformation
BriDoc StageOne -> BriDoc StageTwo
. This is rather sad, as it would have allowed us to restrict which constructors exist in which stages, so we could statically ensure things instead of having ugly stuff such asBDAlt{} -> error "briDocLineLength BDAlt"
around (see Backend.hs).