Re: GHC plugin authors?

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/3f3ae60a796061b... 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 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs