[GHC API stability] Update #1

#1

Hello! After a couple of weeks since the initial call, I’ve received requirements of the following kinds:

  1. Proposals to generalize and extend the GHC implementation for particular use cases. These could help evolve the GHC API eventually.

  2. Requests about how the interface should be organized in layers and components. These are not about features to offer, but rather how features should be provided via some design guidelines or principles. These could inform a future implementation effort.

And I’m aiming for the first deliverable to list and group these requests. But at the moment I have feedback from the authors of only a couple of tools. Besides collecting more requests, I also will need feedback of a third kind.

The third kind of feedback is the minimum set of GHC features a project needs to have stabilized to save some maintenance effort. Different projects entangle with GHC to various depths. Instead of (or in addition to) defining everything the project needs, I propose that we try to identify these subsets, which could help decide what to include in a first iteration of a stable set.

Thanks to everyone who has reached so far, and if you haven’t reached but have an opinion, or a project that uses GHC as a library, I’d love to hear from you! Either public messages or direct emails work.

Cheers!

16 Likes
GHC API: Call for requirements
#2

Replying here for my convenience.

I sometimes maintain GitHub - HeinrichApfelmus/hyper-haskell: The strongly hyped Haskell interpreter. , and interpreter for Haskell that has a graphical interface, and I sometimes also work with GitHub - agda/agda2hs: Compiling Agda code to readable Haskell.

It’s hard for me to pin down exactly what I would need from a stable GHC API because:

  • For hyper-haskell, I rely on the external package hint that takes care of most of the maintenance burden for me, at the price of not offering all features.
  • It’s hard to separate compiler “internals” from the GHC API — if the API does the job well, then the compiler may itself rely on that API.

That said, I can think of broadly two avenues that would help my use cases:

  • Working with cabal and package databases. I think that the more recent GHC environment do most of the heavy lifting here, but I find configuration through environment variable GHC_ENVIRONMENT both welcome and weird.
  • Better separation of parser / pretty-printer / type-checker / compiler / bytecode. For some use cases, specifically agda2hs , it’s interesting to transpile an alien surface syntax to Haskell surface syntax while having some support from the type checker.

The two themes are probably best summarized as “separate components with pure interfaces” that can still cope with “projects that span multiple source files, packages and even languages”.

2 Likes
#3

Thanks for your thoughts @HeinrichApfelmus. A more explicit or functional-style API for GHC environments and better separation of compiler passes is a request shared by other tooling authors indeed.

After examining the dependencies of agda2hs, it doesn’t seem to depend on the ghc package. Does it depend on some other way on the GHC API? Your opinion is still helpful if it doesn’t. I only want to check my understanding of the relationship between the tools.

1 Like
#4

No, that’s correct, at this point in time, agda2hs does not depend on the GHC API.

However, agda2hs generates Haskell code, and may additional want to parse Haskell code in the future, so the option of using the GHC API for both cases is always on the table (see e.g. issue 274). This potential use may be indirect, e.g. through the ghc-source-gen package.