The command line option that was found that allows for Haskell source code to be preprocessed accepts a Haskell source code file as an argument. This file defines a preprocessor. It seems to me that such a preprocessor would be undisciplined and capable of wrong doing because the Haskell language does not have all the facilities that a utility such as Happy possesses. Care is needed. It also lacks those facilities that are particular to preprocessors.

The paper at http://people.cs.uu.nl/arthurb/data/Macros/Manual.pdf may provide a means to introduce this needed discipline. I do not see how the runtime verses compile time distinction is important, however. You can't really hand craft a preprocessor on the fly that is going to work. I do not believe the paper is explaining itself all that well. What they are referring to as syntax macros given a superficial examination of the paper seem to be the functional language equivalent of a definite clause grammar found in Prolog. So it seems that an effort to bring that goodness that Prolog programmers have enjoyed for years over to Haskell and perhaps to do one or two better.

Their emphasis on runtime verses compile time seems like a distraction in that it is merely a necessary condition for inclusion into the Haskell language since Haskell is both compiled and interpreted. It is a problem that would need to be solved. They may have lost sight of what they were doing after having spent so much time working on just this one aspect. Haskell at the present time need external tools. The benefits of bringing in that sort of functionality into the language I would regard as self-evident.

It is still a bottom up approach, but a bottom up approach would be easier to implement and it would be desirable for the two worlds to meet, the bottom up and the top down.