expanded macros in parser?

Richard Eisenberg eir at cis.upenn.edu
Wed Nov 12 18:26:20 UTC 2014


Ah -- makes perfect sense. Thanks. Indeed, this improvement is worth the annoyance of writing out the extra parameters.

Richard

On Nov 12, 2014, at 1:16 PM, Austin Seipp <austin at well-typed.com> wrote:

> 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/



More information about the ghc-devs mailing list