help migrating a tool that uses the ghc api

[Sam Halliday]

Thanks to everybody who chimed in on this thread.

I have now updated ghcflags / hsinspect to work with all versions of ghc
from 8.8.3 through to 9.6.1. You can see the churn in various parts of
the ghc api in the commit history
https://gitlab.com/tseenshe/hsinspect/-/commits/develop ... if the
authors of some refactors inside ghc were aware that some of these
functions and data types were being used externally then perhaps they
could have left functions in place that would have continued to work as
before.

I'd like to extract this one part from the thread, and ask if there
would be any objections to me submitting a standalone test file to the
ghc codebase:

> tooling authors can submit test code (in the sense that it is compiled
> as part of the ghc build) to ghc as documentation of their most
> sensitive uses of the ghc APIs. It wouldn't be distributed and
> therefore there is no risk to pollution of the ghc api.

It will take me some time to do this so I don't want to do it without
understanding if it would be accepted. I think it will pay for itself
after about 2 or 3 major releases of ghc, but it mitigates against
anybody removing core functionality that I'm making use of which is the
most important thing.

If that is ok, where should I start? I don't know how to add (or run) a
test file to ghc that would simply test that the file compiles.


Sam Halliday wrote:
> Thanks Simon,
>
> Simon Peyton Jones wrote:
>> What we need is
>>    - An API for GHC that is *designed *and *actively curated*.
>>    ...
>
> Some may believe that the API would need to be some huge reflection of
> the internal API, with maximal reuse in mind. That is a mammoth task,
> but an API could also end up being a lot of the code from tools pushed
> further into the ghc codebase (although perhaps a very inefficient way
> of doing it for everybody if it's going through committees).
>
> I propose an alternative: that tooling authors can submit test code (in
> the sense that it is compiled as part of the ghc build) to ghc as
> documentation of their most sensitive uses of the ghc APIs. It wouldn't
> be distributed and therefore there is no risk to pollution of the ghc
> api.
>
> Breaking changes would require fixing inside the ghc test codebase at
> the point of the breaking change by the author of the change (who
> presumably understands it the most!) and then when ghc is released, the
> tooling author knows exactly what to do to fix their code without having
> to involve the ghc developers any further, except to extend their
> thanks.
>
> One of my biggest fears is that somebody just *removes* something from
> the api entirely and I can't do what I need at all anymore. I don't
> think that kind of problem can be addressed retrospectively.
>
>
>> I know this isn't helping Sam much in the short term -- apologies for that.
>
> Bringing attention to it is helping, so thank you for that. My immediate
> problem can probably be solved by some kind soul dedicating 30 mins of
> their time to help push my code over the line. I'm more than happy to
> barter my own time for something they'd like in return, or send a small
> gift! :-)
>
>
> -- 
> Best regards,
> Sam

-- 
Best regards,
Sam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230522/8931c577/attachment.sig>