help migrating a tool that uses the ghc api

[Bryan Richter]

Hi Sam,

https://gitlab.haskell.org/ghc/ghc/-/wikis/building/running-tests/adding is
a well-written and well-hidden page that explains quite a lot about writing
a test. I'm not sure it's a good idea, though, to add a test to the GHC
test suite that enforces some guarantee that nobody signed up for in the
first place. To put it another way, the CLC proposal process should already
be providing the guarantees you're looking for, and figuring out how to
make that process meaningful and practical regarding GHC's internals is
already stressing the community's limits. I'd suggest to you that you make
a list of the functionality you actually consider "core" and get it into
the hands of the people working on that problem, and I'd suggest to *them*
that they put out a call for other such lists from users of the API.



On Tue, 23 May 2023 at 00:13, Sam Halliday <sam.halliday at gmail.com> wrote:

>
> 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230601/e194d6be/attachment.html>