Re: Dynamically choosing the main function

On 13 November 2017 at 03:47, Ben Gamari wrote:

Harendra Kumar writes:

...

On 12 November 2017 at 23:18, Ben Gamari wrote:

...

In general it's not easy to get a reference to a an arbitrary function in an object file by it's source name. Unless the symbol is exported the compiler is free to optimize the function or even drop it altogether.

I understand that. I was also wondering if there is way (some sort of annotation, pragma or any other workaround) to keep the symbols around without actually exporting them. Exporting either clobbers the module interface from user point of view or the modules need a wrapper to avoid exporting such symbols in user exposed modules. I would also expect an option to remove the effect of any such annotation so that the production build is not under optimized because of this. This is in fact one of the problems that I have been facing in general. I do not know of a good way to hide symbols from users but use them in tests and benchmarks during dev. What is the GHC recommended way to achieve this?

The usual way of dealing with this is to expose the symbols from a `.Internal` module.

That's what I meant when I referred to a wrapper module above. However, it requires you to create two modules even if one extra symbol is needed for dev purposes, a lot of boilerplate for a simple thing. Also, the symbols are anyway exposed to the users, we just ask the users to not look at those. I am wondering if using a preprocessor (CPP) conditional around the optional exports is a better way then, you will have to build differently but you won't have to create another module and expose extra symbols? -harendra