[GSoC 2023] Call for Ideas

Announcements
#1

Google Summer of Code is a long-running program by Google that supports Open Source projects. Haskell has taken part in this program almost since it’s inception!

It allows everyone (since 2022, before that it was only students) to contribute to projects for a stipend. However, in order to do that, we need to have some ideas of what to contribute to.

In the past, this has led to many improvements for GHC, Cabal, HLS, Hasktorch… and it can include your project as well! This is a great way to find contributors for your project (even after the summer ends) – many past participants have become involved long-term.

You can find more info and instructions on how to participate here: https://summer.haskell.org/ideas.html.

15 Likes
#2

Here’s a sketch of an idea that could be interesting for a GSoC project for which I’d like community input.

A migration tool to help code bases move across ghc versions.

It seems to me that not all breaking changes and deprecation warnings can be addressed the same way. However, some breaking changes could potentially be fixed automatically be a Haskell specific tool.

Consider the deprecation of * for Type in the kind signatures. A simple regex would not be able to address this easily, * might show up in many different places.

A Haskell specific tool could address this by doing a static analysis of the source and identifying * in kinds standing for Type by use of the ghc api (or ghc-wrappers) (because * in the kinds might also mean Nat multiplication).

Granted, the “rule” to migrate * to Type might not be trivial, but hopefully would only need to be done once.

So, I think it would be interesting to do something along the lines of:

  • Investigate the breakage issues on existing code bases stuck on 8.10 trying to migrate to 9.0, and from those identify the ones that could be automated through static program analysis

  • Develop an embedded language in Haskell that would work a bit like regex (you would write an expression that is expected to match against programs), but much more sofisticated using operators to e.g. match against a GHC HsType constructor.

    • In pseudo-code, the * to Type rule could be like replace (/HsStarTy/g) (type @Type)

  • Develop the tool that executes the rules possibly interactively with user controls

  • Write rules for 8.10 → 9.0 transition

Again, this is just an over simplified sketch, but I’d like to hear your opinions

1 Like
#3

There is previous work on these refactoring tools:

1 Like
#4

CI-driven Package Release Automation

Haskellers share a lot of code in various libraries, published on Hackage. Packages declare dependencies, and the bounds of compatible versions of such dependencies. However, when a new version of a dependency outside said bounds is released (e.g., a new version of base), it takes quite some effort to create an publish a new release of such package, now compatible with said dependency version:

  • Make changes to the Cabal project description
  • Push to VCS
  • Test whether things don’t break
  • Create and publish a release
    • Update package version
    • Tag
    • sdist
    • Publish sdist to Hackage
    • Potentially publish documentation to Hackage

For “simple” packages, especially those who are not receiving a lot of code changes (anymore), this can be quite tedious. Luckily, it is possible to automate a lot of this, e.g., using GitHub Actions.

I think it’d be good to have a standardized setup package maintainers (using GitHub/GitHub Actions) could apply to their repository so a lot of this is automated, and packages automatically share best-practices in release automation.

Since Dependabot doesn’t support Haskell, some automation around cabal outdated and a cron-like job could be used. Similarly, GHC versions and testing against compatible versions could be based on GHCup metadata.

In the end, once a package author has “finished” working on some package and enabled the automation, the maintainer should ideally no longer need any manual interactions to keep the package compatible with new versions of dependencies, including getting such newer versions published on Hackage and whatnot. As long as CI passes, of course.

I’m aware the above likely doesn’t (or shouldn’t?) involve a lot of Haskell code, but it would bring a lot of value to the Haskell ecosystem.

1 Like
#5

FWIW, I have roughly this setup for a Python project of mine: Dependabot keeps dependencies updated, its PRs get automatically merged when tests (across multiple Python versions, with 100% coverage) succeed, so there’s a regular flow of auto-merged PRs, and once in a while when I think a new release is warranted (which right now is a “manual” decision), all I need to do is set the new version number in the project metadata file and merge said change. Then CI will detect there’s a new version, run tests, publish the new version to PyPI (it publishes to TestPyPI on every merge to main to ensure said automation works), and publish documentation to GitHub Pages.

So, if a project were to become a GSoC project, I’d be happy to contribute/guide. I once started building something along these lines for Haskell projects, but lack of time got in the way.

1 Like
#6

Improve Calligraphy

I think this tool is great but lacks a little bit of interactivity and functionality. Also, It should use a proper Dot-lang library (last time I checked, it manually interpolates a string to generate the dot file).

The main feature It could provide is some sort of type-chasing, and what is that?. Well, many times I find myself lost into the many many types/functions/type classes/etc… a library can have. It’d be nice if we can see which functions produces some type, which types belong to a type class, etc… The current workflow is tedious and implies manual search in hackage or asking ghci something.

A concrete example: let say you have a function within some sort of DataFrame api.

aggregate :: (Ix i, GrouppedData a) => AggDataFrame i a -> AggStrategy a b -> DataFrame b

from the type we can have the intuition you need some index type, some container which groups the data and a function to aggregate the container, but you don’t really know how to call the function with something that types checks. A tool like calligraphy could return the graph of values which can be used in such a function. Let say calligraphy --show-usage aggregate and it returns a graph like

 /---------\
| aggregate | (Ix i, GrouppedData a) => AggDataFrame i a -> AggStrategy a b -> DataFrame b
 \---------/    ^    ^                                      ^
                |    |                                      |   /---\
|---------| ----|    |                                      |- | sum |
|   Ix    |      |----------------|                         |   \---/
| Int     |      | GrouppedData a |                         |
| Integer |      | [a]            |                         |   /----\
| Bool    |      | Vector a       |                         |- | mean |
|---------|      |----------------|                         |   \----/

This would improve the workflow a lot, and I think it could be integrated with HLS since it depends on hie files, which AFAIK are used by HLS too.

2 Likes
#7

Reminder to folks posting great ideas here: please submit them as PRs (using markdown) to the repository at GitHub - haskell-org/summer-of-haskell: Source code of summer.haskell.org for them to be listed!

#8

Should the PR place them here: summer-of-haskell/cabal-filter.md at master · haskell-org/summer-of-haskell · GitHub ?

I’ve been using Jax recently (a Python deep learning framework). It is very functional (pure, uses scans) and I’m wondering whether bindings (or just a similar package) in Haskell would make sense as a project.

#9

@Lsmor @NicolasT These are alll excellent ideas – would you be willing to mentor? I’m happy to write these up and add them to the website.

@reuben You can create a new file alongside cabal-filter.md.

@romes I quite like this idea but it seems beyond what a student can accomplish in a summer. Maybe building top of some existing work could work?

1 Like
#10

I am willing, but I have very little experience in this. May I get informed about the duties/expectation for mentors?

I have PR the calligraphy project to summer-of-haskell repo :slight_smile:. We can keep the conversation over there

1 Like