Do plugins work with cross compilers?
1 Like
If we are going to deprecate language features, let’s make sure they have a at least 2 year deprecation warning phase. If 9.8 would come along deprecating some language features, and breaks code that worked fine in 9.6, we are on a sure way to kill haskell adoption.
4 Likes
In that case, they can’t be repackaged as plugins 
It would significantly regress GHC. On the other hand, if we make plugins properly compatible with cross compilers, then, yes this might be a good solution to make ghc more modular and lighter. I’m not sure how much of a performance impact it might have, and if we’d run into ordering issues (plugins x, needs to run before plugin y, …).
1 Like
-
Ordering issues: start with the “lowest-hanging fruit” - plugins which can be used in any order…
-
Compatibility issue (with cross compilers): “low-hanging fruit” apparently all gone, so bring the chain-saw e.g. make the back-section (containing the code generator) into a standalone program which takes C-- as input.
1 Like
This is pretty close to what @csabahruska actually does.
Multi-target GHC might be workable middle ground as well. Getting plugins to work with cross compilers is actually something we should fix.
So, I’d rather advocate for:
- fix plugin defects today
- consider moving extensions into plugins.
- build plugins on demand (even for novel extensions).
1 Like
…and also HBC: it had a standalone code generator in addition to the one in the primary executable, lmlcomp. For some reason, a different choice was made for GHC, and here we are.
1 Like
I know some people use them, but I’d love to see TupleSections gone so that we could have (unambiguous) trailing commas for e.g. list syntax. It such an annoying syntactic wart that has led to the bizarre “leading comma” formatting workaround-but-not-really-a-workaround.
(I’d love to see just how necessary TupleSections really are compared to how many people could use trailing commas. I’d bet the ratio at least 100-to-1 in favor of trailing commas)
3 Likes
I’d be happy to see AlternativeLayoutRule gone, since it makes the lexer quite a bit more complex, while the extension itself is so obscure that it’s not even documented in the User’s Guide.
9 Likes
AlternativeLayoutRule isn’t alone:
…and undoubtedly there will be disagreement about that list, as well as the other suggestions already here and elsewhere. All we can do is “hurry up and wait” e.g. for plugins to work everywhere, or “join in the fun”…
2 Likes
From my perspective the two features which incur large maintenance burden on my day-to-day work are safe haskell and backpack.
For each developer their list will be different, I mostly work on driver related code so regularly my work gets stalled on fixing an assumption or misimplementation in the backpack code. This does lead to frustration but also a low level of confidence that the backpack implementation is robust for serious use.
16 Likes
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