Support sum type layouting #294
No reviewers
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#294
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "eborden/eborden/sum-data"
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?
@lspitzner Getting the ball rolling on this topic.
This is a naive first pass at sum type support. This currently breaks 11
tests, some from comment misplacement, others in more exotic forms that
previously required high levels of context to be correctly laid out. The
solution for comment misplacement is probably trivial, but the highly
contextualized forms may need a bit more alchemy.
Super excited to see progress here 👏, thanks Evan!
I just happened to notice something in the test cases that might be worth a little bike-shedding, if it's still easy to change things at this stage:
This is interesting to me in terms of consistency, given the possible non-sum styles of:
In our own code base, we've shifted between (1) and (2): our "before my time" Style Guide has examples in style (2), but we aren't sure it was intentional and most of the current team prefers (1), so we most often use that style now.
Doing (1) for non-sums feels consistent with this sum test case: i.e. you only drop the
=
if some|
s are coming, and{
is always indented one column further than above.Doing (2) for non-sum feels inconsistent to me since the
=
is always dropped but the{
is only indented for sum-type cases.I actually think aesthetically I do like this PR as-is, but I thought it was worthwhile to raise the consistency point. At the end of the day, "I don't care as long as it's automated" always wins (and sums-with-records is something we avoid generally), but if there's ever a time to actually dig in on a style discussion, it's probably when that automation itself is being written 😄
Sorry that I have not given any feedback yet, and thanks for starting on this feature. First I got sidetracked by refactoring around butcher/czipwith/barbies/commandline-/config-parsing and today I started restructuring the test-suite.
This PR is a good start. but it needs more tests. Both to clear up the discussion on desired layout similar to what @pbrisbin mentions (and some existential/constraint/multiple-constructor/non-single-line combinations are non-trivial) and to get a tiny bit of coverage over the implementation.
I noticed the
docPar (docLit "")
trick that is very useful for several different cases and I had not realized it. Can probably clean up some existing layouter code with it :-) (which of course will be unrelated to this PR.)(there are also some redundant patterns in this PR's code, but I'll just clean them up while fixing comment behaviour probably.)
My workspace is currently a half-broken mess; I'll try to push something in the next days.
Hello, is there any progress on this PR or is it stuck on something? It would be absolutely fantastic to have support for sum types in Brittany.
@vaclavsvejcar This isn't stuck for any particular reason. I think myself and @lspitzner have just not had the time to dedicate to it.
Step 1:
From your project repository, check out a new branch and test the changes.Step 2:
Merge the changes and update on Gitea.