On 13 November 2017 at 03:47, Ben Gamari <[email protected]> wrote:
> Harendra Kumar <[email protected]> writes: > > > On 12 November 2017 at 23:18, Ben Gamari <[email protected]> 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
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
