Yes, the grammar is the Happy parser. It isn’t perfect, but it’s quite close to being a usable grammar, and where the parser doesn’t fit into a nice LR box, there are comments to show what the intention is. This is exactly what’s done in GHC proposals.
My point is that you’ve made a claim that something is simplified, but haven’t done any of the work to see if that’s true. Neither you nor I know if it’s actually simpler in the presence of fundeps (which overlaps with type grammar). I’d encourage everyone making claims about significant, breaking change proposals to be thorough.
I should clarify this. I think <= is “excrutiating” because it puts a significant wrinkle in an implementation of ConstraintKinds, which requires that constraint syntax and type syntax be unified. It’s acceptable right now (as much as it can be) because we don’t allow type operators in constraints. In the event that we do merge constraint and type grammars (I’ve already done this in purescript-language-cst-parser, unofficial of course), then the <= syntax becomes ambiguous, and we have to disambiguate it by only allowing type operators in constraint heads if it’s wrapped in parens. It’s a very tedious and unexpected restriction for what I consider to be a purely aesthetic choice. If I were to avoid this, I would likely do the simplest thing possible and just switch to => to match Haskell, since my experience is that the “implies” interpretation of the arrow is not obvious to newcomers.
Under that reasoning, your proposal has the same issues as <=, since functional dependency syntax overlaps with type syntax. I think that it creates an equivalence between constraints and functional dependencies (where there is none) since it uses identical syntax. I’d say this equivalence is reflected in a grammar ambiguity that needs to be accounted for some how. It’s possible, yes, that we could also have totally different syntax for functional dependencies, but I think that at that point, it’s snowballing very quickly. My experience in dealing with breaking language changes (having introduced one recently!) warns me that the long-tail pain of such a change is not worth it. That’s the case for any syntax-only change, since the trade-off to tip the scale is usually more language expressivity.
I’ve seen <= enough now that I’ve started to read it just fine, but I can say with relative confidence that the following syntax would have been a it more intuitive when I first picked up PS.
class Category a where
instance Semigroupoid a
identity :: forall t. a t t
instance Category (->) where
identity x = x
I would read this as: "To have an instance of Category, you must be a (already have an instance of) Semigroupoid and implement identity. So a class declaration looks like a indented list of things that must be true in order to have an instance of the given class.
Not that it being a bit more intuitive for one guy to grasp is reason to change it
