Dynamically choosing the main function

[Harendra Kumar]

On 13 November 2017 at 03:47, Ben Gamari <ben at smart-cactus.org> wrote:

> Harendra Kumar <harendra.kumar at gmail.com> writes:
>
> > On 12 November 2017 at 23:18, Ben Gamari <ben at smart-cactus.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171113/7a07134e/attachment-0001.html>