Add infix flag for class and data declarations

At the moment, data and type declarations using infix formatting produce the same AST as those using prefix.

So

type a ++ b = c

and

type (++) a b = c

cannot be distinguished in the parsed source, without looking at the OccName details of the constructor being defined.

Having access to the OccName requires an additional constraint which explodes out over the entire AST because of its recursive definitions.

In keeping with moving the parsed source to more directly reflect the source code as parsed, add a specific flag to the declaration to indicate the fixity, as used in a Match now too.

Note: this flag is to capture the fixity used for the lexical definition of the type, primarily for use by ppr and ghc-exactprint.

Trac metadata

Trac field	Value
Version	8.0.1
Type	Task
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	mpickering
Operating system
Architecture

changed milestone to %8.2.1

changed weight to 5

added Ttask Trac import labels

I'm all for capturing the source syntax in the AST, so thumbs-up from me.

I don't understand this comment though

Having access to the OccName requires an additional constraint which explodes out over the entire AST because of its recursive definitions.

I'm sure you are right, but what additional constraint?

The additional HasOccNameIdconstraints were introduced in D2752, this patch should remove them again.

E.g.

pp_vanilla_decl_head :: (OutputableBndrId name, HasOccNameId name)
   => Located name
   -> LHsQTyVars name
   -> HsContext name
   -> SDoc
pp_vanilla_decl_head thing (HsQTvs { hsq_explicit = tyvars }) context
 = hsep [pprHsContext context, pp_tyvars tyvars]
  where
    pp_tyvars (varl:varsr)
      | isSymOcc $ occName (unLoc thing)
         = hsep [ppr (unLoc varl), pprInfixOcc (unLoc thing)
         , hsep (map (ppr.unLoc) varsr)]
      | otherwise = hsep [ pprPrefixOcc (unLoc thing)
                  , hsep (map (ppr.unLoc) (varl:varsr))]
    pp_tyvars [] = ppr thing

And I just realised the issue statement is wrong, the constraints are on the Outputable instances for the AST, not the AST itself.

And it seems the HasOccName constraint is also required for pprMinimalSig, via

pprBooleanFormulaNormal :: (Outputable a, HasOccName a)
                        => BooleanFormula a -> SDoc
pprBooleanFormulaNormal = go
  where
    go (Var x)    = pprPrefixVar (isSymOcc (occName x)) (ppr x)
    ...

assigned to @mpickering and unassigned @alanz

I didn't notice this before but there is something wrong with this constraint and we should clean it up before someone forgets.

The first thing which is wrong is that it already nearly exists in GHC and is called NamedThing, so we should just try to use that rather than this new class.

The second thing, in both cases it is used to check whether a variable is an infix operator or not and then either calls pprInfixOcc or pprPrefixOcc. It would seem better to add a new method to OutputableBndr which also does this check rather than do it every time we need to know. Something like pprInPos :: (SDoc -> SDoc) -> (SDoc -> SDoc) -> SDoc where the two continuations describe how to deal with the two cases that the indentified is infix or prefix might be better.

Another very good question is why pprBooleanFormulaNormal isn't parametrised by OutputableBndr as well when it very clearly outputs Bndrs.

assigned to @alanz and unassigned @mpickering

NamedThing has a method getName :: a -> Name which is meaningless in the RdrName case for the ParsedSource.

I see that OutputableBndr has class methods pprPrefixOcc, pprInfixOcc :: a -> SDoc which will work for the BooleanFormula case.

Trac metadata

Trac field	Value
Differential revisions	- → D2828

mentioned in commit 8f6d241a

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added Pnormal label