with -traditional concatenation is not available.

#define RET(x) x #define CONCAT(x,y) RET(x)y On Fri, 15 Feb 2013 11:17:20 +0000 Geoffrey Mainland 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 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 ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

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 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 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 ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Your ship was destroyed in a monadic eruption.