# Ideas for Master's thesis

**URL:** <https://discourse.haskell.org/t/ideas-for-masters-thesis/10008>\
**Category:** Uncategorized\
**Created:** [July 23, 2024, 2:12pm UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008 "2024-07-23T14:12:23Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![apoorvaanand](https://avatars.discourse-cdn.com/v4/letter/a/8edcca/32.png) [@apoorvaanand](https://discourse.haskell.org/u/apoorvaanand)\
**Post date:** [July 23, 2024, 2:12pm UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/1 "2024-07-23T14:12:23Z")

</div>

Hi everyone!

I am looking for inspiration/ideas for my master’s thesis. I will have a year to do it and I am familiar with Haskell, FP and PL theory (with a little bit of language-based security). I don’t mind doing front-end GUI stuff either.

I would love to pick your brains’ imagination on something that would be interesting and useful to work on (implementation in Haskell of course :)). Or if you could point me to papers that contain ideas that can be explored in a Master’s thesis.

---

<div class="post-metadata">

**Author:** ![LaurentRDC](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/laurentrdc/32/4950_2.png) [@LaurentRDC](https://discourse.haskell.org/u/LaurentRDC)\
**Post date:** [July 23, 2024, 2:26pm UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/2 "2024-07-23T14:26:46Z")

</div>

In what fields are you interested?

In a vacuum, I think the ideas behind [Cloud Haskell](https://simon.peytonjones.org/assets/pdfs/haskell-in-the-cloud.pdf) are really cool and could be explored further. [Here’s an implementation](https://haskell-distributed.github.io/) on which you might want to hack.

---

<div class="post-metadata">

**Author:** ![TeofilC](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/teofilc/32/3987_2.png) [@TeofilC](https://discourse.haskell.org/u/TeofilC)\
**Post date:** [July 23, 2024, 2:32pm UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/3 "2024-07-23T14:32:16Z")

</div>

I’m not sure if this is the right size but [Implement "Principled parsing for indentation-sensitive languages" · Issue #235 · haskell/happy · GitHub](https://github.com/haskell/happy/issues/235) would be a cool project for someone (if they’re a fan of parsers). There’s been a few academic papers on the topic, but there’s still some work to figure out how to have a nice syntax for this, which approach is best, and to get a version merged into happy.

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [July 23, 2024, 5:03pm UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/4 "2024-07-23T17:03:59Z")

</div>

I do not know if this clears the threshold but a Haskell library that can amend the substantive content of a YAML file without (or minimally) disturbing its existing formatting and yielding something formatted consistently with the original (all from the perspective of a human being reading the same file) would be super! EDIT: If that is ‘too small’, the general case of formats designed to be used by both people and machines, with YAML and Cabal files as specific examples.

---

<div class="post-metadata">

**Author:** ![sgraf](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/sgraf/32/392_2.png) [@sgraf](https://discourse.haskell.org/u/sgraf)\
**Post date:** [July 23, 2024, 5:18pm UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/5 "2024-07-23T17:18:29Z")

</div>

Depending on how willing you are to delve into a large code base, you could

1. try rewriting the generalised LR backend of the [`happy`](https://github.com/haskell/happy) parser generator into a more efficient form that could compete with the LALR backend. I’m not sure where the ceiling is here, but my hope is that the perf on unambiguous phrases would be comparable to the LALR backend.
2. use the GLR backend in GHC’s parser to get rid of the [unfortunate disambiguation mechanism](https://gitlab.haskell.org/ghc/ghc/-/blob/b57792a804ad71986238467abe6917406ffaeae5/compiler/GHC/Parser/PostProcess.hs#L2173) that is currently necessary in situations like

```haskell
do { Con a b <- x } -- 'Con a b' is a pattern
do { Con a b } -- 'Con a b' is an expression

```

3. Measure perf and hopefully declare victory!

Caveat: These were loose thoughts I had over the past couple of years; I have not investigated if (2) really can completely replace the mechanism. But that’s how research experiments work, I suppose.

I imagine that for (3) it could be quite important to have a very fast unambiguous case, that is, where the graph-structured stack has only a single item at the top, as in LALR.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [July 24, 2024, 12:00am UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/6 "2024-07-24T00:00:49Z")

</div>

From [An Implementation of the Haskell Language](https://www.spinellis.gr/pubs/thesis/MEng/html/haskell.pdf) (1990) by Diomidis Spinellis:

> [@](#):
>
> (page 31 of 97)
> 
> **2.6 The layout rule**
> 
> As explained in section 1.3 not all layout rules can be resolved by the lexical analyser. The rule that specifies that a brace needs to be inserted whenever the next item is illegal, but a brace would be legal is more easily handled by the parser. […]

The layout rule referred to there still exists in the current Haskell ([2010](https://www.haskell.org/definition/haskell2010.pdf)) standard:

> [@](#):
>
> (page 153 of 329)
> 
> ```
> _L_(_t_:_ts_) (_m_:_ms_) = } : (_L_(_t_:_ts_)_ms_) if_m_/= 0 and parse-error(_t_)
> (_Note_5)
> ```

Your challenge, should you decide to accept it, would be to implement a suitable alternative to this _“syntactic wrinkle”_, one that finally allows the lexing and parsing of Haskell to be properly separated…

---

<div class="post-metadata">

**Author:** ![ocramz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ocramz/32/3713_2.png) [@ocramz](https://discourse.haskell.org/u/ocramz)\
**Post date:** [July 24, 2024, 4:14am UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/7 "2024-07-24T04:14:58Z")

</div>

In a MSc thesis it’s important that your supervisor(s) are at least knowledgeable in the field to guide you around any major issues you might encounter. This constrains the choice of topics in a way.

If I had a clean slate though, I would explore applications of **staged metaprogramming** (in which the statically-known part of a program is produced and optimized at compile time). One of the coolest recent examples in Haskell is Parsley : [parsley: A fast parser combinator library backed by Typed Template Haskell](https://hackage.haskell.org/package/parsley) .  
I’ve done some exploration of this approach for numerical computing (linear algebra) and I think it could be applied elsewhere too.

---

<div class="post-metadata">

**Author:** ![OrenGitHub](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/orengithub/32/4495_2.png) [@OrenGitHub](https://discourse.haskell.org/u/OrenGitHub)\
**Post date:** [July 24, 2024, 5:01am UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/8 "2024-07-24T05:01:23Z")

</div>

Hi,

- I have a Phd in programming languages, and I’m writing an [open source security container scanner](https://github.com/OrenGitHub/dhscanner).
- If your supervisor approves, there are a lot of challenges related to static code analysis in this project.
- Feel free to write here if it’s relevant

---

<div class="post-metadata">

**Author:** ![LaurentRDC](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/laurentrdc/32/4950_2.png) [@LaurentRDC](https://discourse.haskell.org/u/LaurentRDC)\
**Post date:** [July 24, 2024, 1:34pm UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/9 "2024-07-24T13:34:00Z")

</div>

Another suggestion: anything to do with algebraic graphs.  
[See here for a library that implements them](https://github.com/snowleopard/alga).

If I remember correctly, all constructable graphs are valid – that’s awesome! However, the ergonomics of them could be improved. [See this issue for example](https://github.com/snowleopard/alga/issues/95).

I have tried to improve a little on them ([see here](https://github.com/PowerweaveInc/powernet)). You might be interested in taking this further

---

<div class="post-metadata">

**Author:** ![olf](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/olf/32/3813_2.png) [@olf](https://discourse.haskell.org/u/olf)\
**Post date:** [July 25, 2024, 10:08am UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/10 "2024-07-25T10:08:13Z")

</div>

Another topic which IMHO would do the Haskell community a tremendous deed is auto-generating forms (in the sense of data entry systems) for `Generic` data types. For a thesis, this would mean to (1) flesh out what exactly characterizes a form [\*], and (2) provide some proof-of-concept implementations for various form incarnations, e.g. [HTML forms](http://discourse.haskell.org/t/generalizing-yesod-form-massinput/8106).  
An implementation that works for `IO` as the form monad can be found [here](https://hub.darcs.net/olf/GenericForm).

Other functional languages like Clean have these.

[\*] If we allow recursive, possibly infinite types, then forms must be dynamic and possibly stateful. For systems like HTML one must be able to attach unique identifiers to every input field of a form, otherwise marshalling the posted data into Haskell would be impossible.

---

<div class="post-metadata">

**Author:** ![olf](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/olf/32/3813_2.png) [@olf](https://discourse.haskell.org/u/olf)\
**Post date:** [July 25, 2024, 10:36am UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/11 "2024-07-25T10:36:05Z")

</div>

At first sight the inherent problem is that the semantics mentions set union, while there is no such thing in Haskell unless you are willing to constrain the node type. This is also relevant for the `Foldable` and `Traversable` issues as for those one might implicitly assume each vertex is traversed exactly once.

---

<div class="post-metadata">

**Author:** ![ocramz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ocramz/32/3713_2.png) [@ocramz](https://discourse.haskell.org/u/ocramz)\
**Post date:** [July 26, 2024, 7:15am UTC](https://discourse.haskell.org/t/ideas-for-masters-thesis/10008/12 "2024-07-26T07:15:36Z")

</div>

> [@olf](#):
>
> do the Haskell community a tremendous deed

OP needs to defend his MSc (formulate research idea, summarize literature, do experiments, summarize results), not do random FOSS work. Whether the former ends up benefiting the latter should be a coincidence, not a goal.