# \[GSoC 2023\] Call for Ideas

**URL:** <https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606>\
**Category:** Announcements\
**Created:** [January 18, 2023, 5:36pm UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606 "2023-01-18T17:36:26Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![jaspervdj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaspervdj/32/586_2.png) [@jaspervdj](https://discourse.haskell.org/u/jaspervdj)\
**Post date:** [January 18, 2023, 5:36pm UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/1 "2023-01-18T17:36:26Z")

</div>

[Google Summer of Code](https://summerofcode.withgoogle.com/) 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](https://summer.haskell.org/ideas.html).

---

<div class="post-metadata">

**Author:** ![romes](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/romes/32/2912_2.png) [@romes](https://discourse.haskell.org/u/romes)\
**Post date:** [January 24, 2023, 4:47pm UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/2 "2023-01-24T16:47:36Z")

</div>

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.

- 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

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [January 24, 2023, 4:54pm UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/3 "2023-01-24T16:54:38Z")

</div>

> [@romes](#):
>
> Develop an embedded language in Haskell that would work a bit like regex

There is previous work on these refactoring tools:

- Retrie: [hackage](https://hackage.haskell.org/package/retrie)
- HaRe: [paper](https://doi.org/10.1016/j.entcs.2005.02.053), [hackage](https://hackage.haskell.org/package/HaRe)

---

<div class="post-metadata">

**Author:** ![NicolasT](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nicolast/32/2872_2.png) [@NicolasT](https://discourse.haskell.org/u/NicolasT)\
**Post date:** [January 25, 2023, 11:30am UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/4 "2023-01-25T11:30:33Z")

</div>

# 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.

---

<div class="post-metadata">

**Author:** ![NicolasT](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/nicolast/32/2872_2.png) [@NicolasT](https://discourse.haskell.org/u/NicolasT)\
**Post date:** [January 26, 2023, 9:52am UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/5 "2023-01-26T09:52:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Lsmor](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/lsmor/32/3302_2.png) [@Lsmor](https://discourse.haskell.org/u/Lsmor)\
**Post date:** [January 26, 2023, 5:30pm UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/6 "2023-01-26T17:30:48Z")

</div>

## Improve Calligraphy

I think [this](https://github.com/jonascarpay/calligraphy) 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.

```haskell
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

```txt
 /---------\
| 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.

---

<div class="post-metadata">

**Author:** ![sclv](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/sclv/32/71_2.png) [@sclv](https://discourse.haskell.org/u/sclv)\
**Post date:** [January 26, 2023, 7:00pm UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/7 "2023-01-26T19:00:45Z")

</div>

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](https://github.com/haskell-org/summer-of-haskell) for them to be listed!

---

<div class="post-metadata">

**Author:** ![reuben](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/reuben/32/4733_2.png) [@reuben](https://discourse.haskell.org/u/reuben)\
**Post date:** [January 28, 2023, 10:58pm UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/8 "2023-01-28T22:58:45Z")

</div>

Should the PR place them here: [summer-of-haskell/cabal-filter.md at master · haskell-org/summer-of-haskell · GitHub](https://github.com/haskell-org/summer-of-haskell/blob/master/content/ideas/cabal-filter.md) ?

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.

---

<div class="post-metadata">

**Author:** ![jaspervdj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaspervdj/32/586_2.png) [@jaspervdj](https://discourse.haskell.org/u/jaspervdj)\
**Post date:** [January 29, 2023, 10:18am UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/9 "2023-01-29T10:18:21Z")

</div>

@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?

---

<div class="post-metadata">

**Author:** ![Lsmor](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/lsmor/32/3302_2.png) [@Lsmor](https://discourse.haskell.org/u/Lsmor)\
**Post date:** [January 29, 2023, 6:51pm UTC](https://discourse.haskell.org/t/gsoc-2023-call-for-ideas/5606/10 "2023-01-29T18:51:43Z")

</div>

> [@jaspervdj](#):
>
> would you be willing to mentor? I’m happy to write these up and add them to the website.

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 🙂. We can keep the conversation over there