GHC's build process uses the system cpp, not cpphs? The two behaved rather differently in my experience.
With regards to #s in names, I found this: http://stackoverflow.com/a/1386732 AFAIK traditional mode is necessary to preserve whitespace, and primops.txt.pp certainly /looks/ like it cares about whitespace, so if that disables concatenation on the other hand then it might be a no-go after all. But following the S.O. answer, maybe concatenation could just be implemented as #define F(X) X, #define CAT(A, B) F(A)F(B)? The cpp on my system right now (OS X) is confusing me by seeming to use traditional mode even when I don't specify it, and not doing anything differently when I do, and clang -E does another thing again and likewise doesn't seem to care about -Wp,-traditional, so I'm not feeling a lot of trust in my own experimentation. On Fri, Feb 15, 2013 at 12:17 PM, Geoffrey Mainland <[email protected]> wrote: > That was what I wanted to do at first, but I don't think it's possible. > > First of all, on Linux at least, we invoke the preprocessor with > -traditional, so concatenation is not available. That could be changed. > > Without -traditional, CPP doesn't like the # characters in the names of > our primops. If you see how to get around that issue, please let me know > :) > > Geoff > > On 02/15/2013 11:08 AM, Gábor Lehel wrote: >> Could it be done with CPP macros perhaps, instead of a separate code >> generator program? If the boilerplate is fairly regular and only >> requires placeholder-substitution, identifier concatenation and >> stringification, it could be an option. Just a thought. >> >> On Fri, Feb 15, 2013 at 11:51 AM, Geoffrey Mainland >> <[email protected]> wrote: >>> Hi All, >>> >>> There is a huge amount of boilerplate involved in adding a full >>> complement of vector primops to GHC. I would like to reduce this >>> boilerplate by programmatically generating the vector primops. My plan >>> is to add utils/genvecprimops and #include its output into >>> primops.txt.pp. >>> >>> Does this sound reasonable? Any objections? While I'm at it, is there >>> any related cleanup I could undertake? >>> >>> Thanks, >>> Geoff >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> [email protected] >>> http://www.haskell.org/mailman/listinfo/ghc-devs > > -- Your ship was destroyed in a monadic eruption. _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
