Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

[Shayan Najd]

In this thread, I am going to raise a topic for discussion. Please share
your opinions and related experiences.

Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a
fixed phase index, such as `GhcPs`, gives us distinct ASTs at the
*compile-time*.
However, when programming with these ASTs, we use patterns, such as `HsMultiIf
:: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared
among phases.
We can
(1) introduce a layer of abstraction providing a set of type and pattern
synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS  LPsExpr]
-> PsExpr`; and
(2) updating code working on ASTs of specific phase to use the interface
specific to the phase, such as by changing prefixes from `Hs` to `Ps` and
by removing unused variables and placeholders; and
(3) leaving untouched code working uniformly on ASTs of different phases
(i.e., the generic functions in Trees that Grow terminology), such as the
existing functions whose types are polymorphic on phase index.

Some comments:

- It can be done gradually and smoothly: we add three separate files in
HsSyn (per each phase) containing the phase-specific interfaces, and
gradually import them and do the changes per module.
- Using the interfaces is optional: code using the current method (e.g.,
using `HsMultiIf`) should work just fine.
- It introduces a layer of indirection and three more files to maintain.
- It makes code working on HsSyn ASTs, such as the renamer, appear cleaner
as placeholders and similar machinery are abstracted away by the interfaces
(e.g., no need to import bits and pieces of `HsExtension`)
- In theory, there should be zero impact on GHC's runtime performance.

I am myself undecided about its benefit-cost ratio, but willing to at least
implement the phase-specific interfaces.
For me, abstracting away all the `PostRn` stuff, `Out` prefixed
constructors, and dummy placeholders from the front-end code is the most
valuable.

Yours,
  Shayan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170823/e2d5d58a/attachment.html>