expanded macros in parser?

[Austin Seipp]

It was mostly just superfluous macros at least IMO, which is why I
accepted it. The double-preprocessing we do has been annoying in the
past as well (e.g. Clang's preprocessor had issues with it), and any
attempt to use macros that you want to persist *beyond* the first CPP
pass are annoying. For example, the double step makes it very annoying
to use something like __GLASGOW_HASKELL__ inside the parser, since we
want it to persist into Parser.y, past the first step - as opposed to
CPP gobbling it up in the first pass by itself when it sees the `#if`
part.

Another reason I wanted this done is because I eventually would like
to make the 'make sdist' target not depend on a full build. Right now
we depend on there being an inplace build before running `make sdist`
so we can bundle up the generated parser.

Instead it would be ideal if you could immediately './configure; make
sdist' for everything to work. The need for the double-step of
preprocessing is just another annoying component of having to deal
with this in the Makefile rules. It could be done, but it's more
annoying.

On Wed, Nov 12, 2014 at 11:27 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Hi devs,
>
> I just stumbled across commit 37d64a5, which (among other things) expands all the LL/L1/etc macros in Parser.y.pp and makes the go-to file Parser.y. Why was this done? I don't love macros, but I think the old format was easier to look at and edit.
>
> I know I missed the train a bit on this by not noticing D411, but this surprised me today.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/