Thanks for the response @mpickering
Do you have a sense for backpack and its future development? Are there industry/research that are interested in its future?
1 Like
Seven year old issue for deprecating RelaxedLayout, AlternativeLayoutRule, and AlternativeLayoutRuleTransitional.
These three parsing-related language extensions were introduced some time ago yet are likely not used in the wild as they still are not registered in Cabal’s language extension list
Looks like a GHC proposal is in order @int-index. How difficult is writing this proposal? I can help/do it myself if it’s not too difficult.
4 Likes
The main challenge would be to figure out what to do with :set +m in GHCi, which seems to rely on AlternativeLayoutRule.
3 Likes
Why does this exist… it can all be achieved by using regular functions.
This is poorly documented, arcane, not much used.
Not useful and superseded by GADTs.
Superseded by StandaloneKindSignatures.
I use TupleSections all the time, tutorials on applicatives often use it. I don’t really miss trailing commas. But we’re suddenly talking about the user viewpoint. Let’s return to the GHC dev viewpoint! Are TupleSections hard to maintain? I’d be surprised.
3 Likes
Sorry about the Thread Necromancy here, but… No. They’re not a problem to maintain. They’re a problem because they prohibit other, perhaps more generally useful, syntax.
(They’re mutually exclusive, syntactically.)
EDIT: I’m happy someone has found them useful. I have literally never enabled TupleSections in 15+ years of usnig Haskell.
2 Likes
He he. Funny how YMMV. I’d say:
GADTs not useful. Would be superseded by DatatypeContexts – if only they worked per GHC up to 1999. (Apparently the H98 Report was ambiguous as to how they should work; the two main compilers took different implementations. SPJ thought the Hugs approach was not useful [I agree]; but Wadler disagreed and won the argument.)
I’ve tried and tried to get a sensible use for GADTs. Always I find they just push the awkward code to some other place in the program. And I don’t want to store dictionaries inside my datatypes. These days I don’t use GADTs; I use pattern synonyms to apply the constraints.
I find TupleSections moderately useful.
But yeah, fair enough. I’ll shut up.
1 Like
GADTs not useful
Both Yampa and Copilot use GADTs, but that is not to say that the same code could not be written with a different extension.
2 Likes
Oh I’m not denying GADTs are useful to some folks. Just that DatatypeContexts would be more useful to me – if only they were implemented different. So in terms of continuing support inside the compiler: keep the syntax reserved for futures use; don’t chop out the code behind it, because it’ll be useful to refer to for future re-implementation.
1 Like
Just want to point out that GADTs are not just about having data type constructors with constraints (and thus have them store dictionaries), but rather about introducing local equality constraints that further allow you to use types to express invariants and such.
In fact, (one of) the most canonical example of GADTs (Vec) doesn’t use type class constraints at all, and actually, the other common example, creating an AST for expressions using GADTs doesn’t either.
I’m on the phone so I’ll pass on writing down the examples. Also, there are comprehensive write ups that do great explanations (if someone wants to link to them, could be useful).
(As I’m afraid someone might read that and take away GADTs=adding type class constraints/runtime dicts to datatypes)
5 Likes