[wg-camlp4] Pending issues

[David Waern]

2013/2/11 Alain Frisch <alain.frisch at lexifi.com>:
> 5. Fork Parsetree or clean it up?
>
> Hongbo has proposed that we introduce a different representation of the
> Parsetree on which -ppx rewriters would be applied.  Concretely, we could
> fork parsetree.mli into parsetree.mli/ast.mli, clean up parsetree (see
> below) and adapt parser.mly accordingly, and then implement a translation
> pass from Parsetree to Ast before running the type-checker on Ast.  The
> alternative is to clean up Parsetree directly and adapt the type-checker to
> these changes.  This avoids an extra intermediate language and the mapping,
> but this could add a little bit of extra complexity to the type-checker (and
> it might be more difficult to convince core developers).  What do people
> think?

I'm not a core developer, but I vote for cleaning up Parsetree rather
than forking it. Advantages:

  - one single (clean) type
  - the typechecker can produce error messages closer to what the user wrote

The Haskell compiler (GHC) does typechecking on the non-desugared
version of the syntax for exactly the second reason, and the
developers seem to have been quite happy with that decision.

Another note: in the Haskell land there are multiple different syntax
tree types floating around:

   - the aforementioned front end type
   - another one used in Template Haskell
   - a third type (in the "haskell-src-exts" library) that is designed
to be as clean and easy to use as possible

Most stand-alone tools are implemented using the third type since it's
by far the easiest one to use. I have heard many people (including GHC
core developers) whishing they would have just one clean type.

David