Effects: 

Some cleanup and tidying to prepare for adding the HProp. 

Lots of crosscutting changes, so want to merge sooner rather than later.
I agree the current solution is not perfect -- I don't want initialization scattered -- but that that rule has strictly lower priority than the inviolable 15-line-maximum.

The ideal would be to perhaps break the monster ghc spec structure into a few smaller sub structures following the "CHOP" functions which are currently doing a bit of grouping.

Regardless, the earlier gigantic function was a complete non starter. The new one is not great but strictly better and can no doubt be greatly improved upon. 

> On Aug 4, 2014, at 3:46 PM, Eric Seidel <notifications@github.com> wrote:
> 
> In src/Language/Haskell/Liquid/Bare.hs:
> 
> >  
> >  
> >  ------------------------------------------------------------------------------------------------
> > -makeGhcSpec' :: Config -> [Var] -> [Var] -> NameSet -> [(ModName,Ms.BareSpec)] -> BareM GhcSpec
> > +makeGhcSpec' :: Config -> [Var] -> [Var] -> NameSet -> [(ModName, Ms.BareSpec)] -> BareM GhcSpec
> >  ------------------------------------------------------------------------------------------------
> >  makeGhcSpec' cfg vars defVars exports specs
> @ranjitjhala I agree with your argument that big functions should generally be avoided, but I'm not convinced that this is a good solution. I think it's better to have a function that constructs a whole GhcSpec rather than 5 functions that construct (somewhat arbitrary) parts of a GhcSpec. The GhcSpec type has a ton of fields, so there's necessarily going to be a lot of logic involved in constructing one.
> 
> That being said, the existing makeGhcSpec' could certainly be cleaned up. I think a healthy compromise between avoiding large functions and arbitrary division of logic would be something like the following:
> 
> makeGhcSpec args
>   = do (tySigs, asmSigs) <- makeSigs
>        exports <- makeExports
>        invariants <- makeInvariants
>        ...
>        return $ SP { .. }
> i.e. pretty similar to the current structure, but with a hard restriction that we split out generation of each field into a separate function (unless it's natural to group construction of a couple fields, like perhaps tySigs and asmSigs). So, for each field of the GhcSpec we'd have a statement foo <- makeFoo makeFooArgs -- capturing dependencies between fields.
> 
> With this pattern we should be able to cleanly separate the logic for constructing individual fields of the GhcSpec, while retaining a function that provided a holistic view of the entire process.
> 
> —
> Reply to this email directly or view it on GitHub.