When using bnfc to generate haskell code with the --functor option, the
parser will no store the begining position of the corresponding code in
each node. This might be useful, for instance, to report errors.

Note that this is possibly a larger change than it had to be because I
tried something new: instead of generating code by putting together
strings (or the slightly fancier PrettyPrint.Doc), I refactored the code
that makes happy production to generate an AST which is then
pretty-printed. Both the AST types and the pretty printer being of
course generated by BNFC itself! This seems like an obvious thing to do
but for some reason we never did.

The main advantage is that it makes much better use of the type
checker (whene everything is a string, it doesn't mean much that the
type checking passes...).

In addition, you get much cleaner code by getting rid of all the
separators, keywords, symbols and parentheses that are now inserted by the
pretty printer.

When using bnfc to generate haskell code with the --functor option, the
parser will no store the begining position of the corresponding code in
each node. This might be useful, for instance, to report errors.

Note that this is possibly a larger change than it had to be because I
tried something new: instead of generating code by putting together
strings (or the slightly fancier PrettyPrint.Doc), I refactored the code
that makes happy production to generate an AST which is then
pretty-printed. Both the AST types and the pretty printer being of
course generated by BNFC itself! This seems like an obvious thing to do
but for some reason we never did.

The main advantage is that it makes much better use of the type
checker (whene everything is a string, it doesn't mean much that the
type checking passes...).

In addition, you get much cleaner code by getting rid of all the
separators, keywords, symbols and parentheses that are now inserted by the
pretty printer.

When using bnfc to generate haskell code with the --functor option, the
parser will no store the begining position of the corresponding code in
each node. This might be useful, for instance, to report errors.

Note that this is possibly a larger change than it had to be because I
tried something new: instead of generating code by putting together
strings (or the slightly fancier PrettyPrint.Doc), I refactored the code
that makes happy production to generate an AST which is then
pretty-printed. Both the AST types and the pretty printer being of
course generated by BNFC itself! This seems like an obvious thing to do
but for some reason we never did.

The main advantage is that it makes much better use of the type
checker (whene everything is a string, it doesn't mean much that the
type checking passes...).

In addition, you get much cleaner code by getting rid of all the
separators, keywords, symbols and parentheses that are now inserted by the
pretty printer.

When using bnfc to generate haskell code with the --functor option, the
parser will no store the begining position of the corresponding code in
each node. This might be useful, for instance, to report errors.

Note that this is possibly a larger change than it had to be because I
tried something new: instead of generating code by putting together
strings (or the slightly fancier PrettyPrint.Doc), I refactored the code
that makes happy production to generate an AST which is then
pretty-printed. Both the AST types and the pretty printer being of
course generated by BNFC itself! This seems like an obvious thing to do
but for some reason we never did.

The main advantage is that it makes much better use of the type
checker (whene everything is a string, it doesn't mean much that the
type checking passes...).

In addition, you get much cleaner code by getting rid of all the
separators, keywords, symbols and parentheses that are now inserted by the
pretty printer.

When using bnfc to generate haskell code with the --functor option, the
parser will no store the begining position of the corresponding code in
each node. This might be useful, for instance, to report errors.

Note that this is possibly a larger change than it had to be because I
tried something new: instead of generating code by putting together
strings (or the slightly fancier PrettyPrint.Doc), I refactored the code
that makes happy production to generate an AST which is then
pretty-printed. Both the AST types and the pretty printer being of
course generated by BNFC itself! This seems like an obvious thing to do
but for some reason we never did.

The main advantage is that it makes much better use of the type
checker (whene everything is a string, it doesn't mean much that the
type checking passes...).

In addition, you get much cleaner code by getting rid of all the
separators, keywords, symbols and parentheses that are now inserted by the
pretty printer.

This is PR #327.

Effects and TODO (Andreas):
#327 (comment)

We can now look at the user experience (UX).  I tried `--functor` on a tiny grammar for Hutton's razor:
```
EPlus. Exp  ::= Exp "+" Exp1;
EInt.  Exp1 ::= Integer;
```
Then I looked at the products to discover how to use the new feature.

- `Test.hs` is unchanged w.r.t. the version without `--functor`.  This is good.  Yet it did not give me any hints how to use positions.

- `Abs.hs` places an additional parametric value at each AST constructor
  ```haskell
  data Exp a = EInt a Integer | EPlus a (Exp a) (Exp a)
    deriving (C.Eq, C.Ord, C.Show, C.Read)

  instance C.Functor Exp where
  ```
  I think the `Functor` instance can and should now be automatically generated by GHC using the `DeriveFunctor` extension. Also, `Foldable` and `Traversable` can be derived.
  The file `Abs.hs` should give me some clues about the positions that the parser delivers.  I'd favor something along
  ```haskell
  data Position = Position { startLine :: Int, startColumn :: Int }
  data Exp' a = EInt a Integer | EPlus a (Exp' a) (Exp' a) ...
  type Exp = Exp' Position
  ```

- `Par.y`:
  ```haskell
  %name pExp_internal Exp
  %name pExp1_internal Exp1
  ...
  %%

  Integer :: { (Maybe (Int, Int), Integer) }
  Integer  : L_integ  { (Just (tokenLineCol $1), (read ((tokenText $1))) :: Integer) }

  Exp :: { (Maybe (Int, Int),  (Razor.Abs.Exp (Maybe (Int, Int))) ) }
  Exp : Exp '+' Exp1 { (fst $1, Razor.Abs.EPlus (fst $1) (snd $1) (snd $3)) }

  Exp1 :: { (Maybe (Int, Int),  Razor.Abs.Exp (Maybe (Int, Int)) ) }
  Exp1 : Integer { (fst $1, Razor.Abs.EInt (fst $1) (snd $1)) }
  {
  ...
  myLexer = tokens
  pExp = (>>= return . snd) . pExp_internal
  pExp1 = (>>= return . snd) . pExp1_internal
  }
  ```

Issues with the generated parser:

- Concerning the last lines: The simpler code is
  ```haskell
  pExp = fmap snd . pExp_internal
  ```

- `pExp` etc. should have a type signature

- There should be a comment to point out the entrypoints at the end of the file (for better UX).

- (Minor issue, not sure: `pExp_internal`:  better name scheme would be `pExpWithPosition` etc.)

- The `Maybe (Int, Int)` shouldn't be duplicated everywhere.  See comment on `Abs.hs` how to factor out a type of `Position` and types for AST trees with position information.

- Can we get `Position` instead of `Maybe Position`?  I see the `Nothing` comes from the empty list case, but maybe there we could return the position of the following token?

Functor as well as Foldable and Traversable can be derived using the
proper LANGUAGE extensions.

Also: parameterized version of AST is primed, unprimed is
position-carrying:

  type Exp = Exp' BNFC'Position
  data Exp' a = EPlus (Exp' a) (Exp' a) ...

Also abbreviate 'Either String' to 'Err' in generated happy file.

If one runs `bnfc --functor` on two grammars, one does not want two
different (yet isomorophic) definitions of the position
type (generativity problem).

As type synonyms expand to their definition, it is better to use
Maybe(Int,Int) as position type, and only define a synonym.

whenever BNFC'Position is defined.

Fix-up to d90e876

Input is not always 'String', can also be 'Text' or 'ByteString'.

Fix-up 7f21679.