help migrating a tool that uses the ghc api

[Sam Halliday]

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
-------------- 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/20230519/12dbfcc6/attachment.sig>