GHC plugin authors?

[Christiaan Baaij]

Hi Richard,

So there's multiple reasons/aspects as to why I haven't responded
1. Sam's question/seeking feedback on changing the return type for
constraint solver plugins is something Sam and I discussed at HIW using
ICFPs airmeet instance, as in, it was something I suggested.

And the TL;DR of next three reasons: I can't find enough time / need to get
better at time management / need to hand over work
2. While I've had to maintain the
ghc-typelits-{natnormalize;knownnat;extra} constraint solver plugins as
part of maintaining my (and our company's) livelihood, I usually only try
the next version of the GHC module collection (API) when there's a binary
dist of like an alpha or RC.
3. I guess I've become conditioned to just do the regular impedance
matching for every new major GHC release, as can be witnessed by the
following CPP extravaganza:
https://github.com/clash-lang/ghc-typelits-natnormalise/blob/3f3ae60a796061b7a496f64ba71f4d57dedd01db/src/GHC/TypeLits/Normalise.hs#L181-L316
4. I'm a day-time-only programmer, and with our company growing I've had
less time for coding and maintaining software.

With regards to point 2. if I understand correctly, the gitlab CI creates
bindists as build artifacts, is that correct?
I guess it would be helpful if that were advertised more prominently, so
it's easier to test a new branch without having to build GHC.

With regards to point 3. The "blessed" GHC API, i.e. the module called
"GHC", "Plugins", "TcPlugins" (I forgot what their new names are in the
post ghc 9.0 era), were never enough to get everything done that needed to
be done.
That meant one had to reach out to the GHC module collection, which, for
good reasons (the type and constraint system is always under heavy
development), is changing with every major GHC release.
I guess (constraint solving) plugin creators whose day-job or hobby doesn't
include maintaining plugins got burned out by having to keep up with these
changes.
So I wonder how many constraint-solving plugins currently compile against
GHC 9.0, let alone GHC 9.2; and as a consequence I wonder how many people
are interested in these API changes (since they stopped maintaining their
plugins).

Perhaps they are interested though! But simply not registered to this
mailing list. So asking for feedback on both the haskell discourse and the
haskell sub-reddit certainly wouldn't hurt!

Finally, with regards to point 4. Constraint-solving plugins certainly
required some time to get into.
So often my colleagues look to me whenever there's a new alpha or RC out to
upgrade the plugins.
But Sam's changes for solving type family constraints certainly give the
impression that things will easier going forward!
So now is probably the best time to hand over the baton to one of my
colleagues and hopefully they can provide the asked-for feedback.

On Wed, 1 Sept 2021 at 09:21, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Hi Richard,
>
> I believe that this is mostly due to plugin development happening to
> satisfy a plugin need.  I doubt there is a grand unified vision for
> plugins.  And I don't have one either.  I've dabbled with codegen plugins a
> long time ago, these days I'm primarily concerned with plugins having a
> chance to work in cross compilation settings, and even that is still a very
> uncharted area, but Luite has come up with a hack and Sylvain is making
> progress :-) We still don't have the cabal side fixes, where we'd need some
> `plugin-depends` stanza, but all that only makes sense, once we have the
> fundamentals for plugins disentangled in ghc.
>
> I agree that a discussion on discourse might help.  But we won't know
> without trying.
>
> On Tue, Aug 31, 2021 at 9:34 PM Richard Eisenberg <lists at richarde.dev>
> wrote:
>
>> Hi all,
>>
>> I have seen a few posts from Sam Derbyshire here asking for feedback
>> about plugin API design, and the responses have been minimal. This poses a
>> design challenge, because the GHC folk who design the interface are
>> sometimes distinct from the people who use the interface. We're trying to
>> be good, seeking feedback from real, live clients. Is there a better way to
>> do so than this mailing list? Example: we could create a Category on
>> discourse.haskell.org, if that would reach the audience better. Or we
>> could make a repo with issue trackers somewhere simply to track plugin
>> design. What would work?
>>
>> (I recognize that I'm asking in a perhaps-ineffective channel for advice,
>> but I really don't have a better idea right now. Maybe some of you plugin
>> authors are here and will point us in a better direction.)
>>
>> Thanks,
>> Richard
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> 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/20210901/0e06d5ad/attachment.html>