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.
In what fields are you interested?
In a vacuum, I think the ideas behind Cloud Haskell are really cool and could be explored further. Here’s an implementation on which you might want to hack.
I’m not sure if this is the right size but Implement "Principled parsing for indentation-sensitive languages" · Issue #235 · haskell/happy · GitHub 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.
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.
Depending on how willing you are to delve into a large code base, you could
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.do { Con a b <- x } -- 'Con a b' is a pattern
do { Con a b } -- 'Con a b' is an expression
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.
From An Implementation of the Haskell Language (1990) by Diomidis Spinellis:
The layout rule referred to there still exists in the current Haskell (2010) standard:
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…
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 .
I’ve done some exploration of this approach for numerical computing (linear algebra) and I think it could be applied elsewhere too.
Hi,
Another suggestion: anything to do with algebraic graphs.
See here for a library that implements them.
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.
I have tried to improve a little on them (see here). You might be interested in taking this further
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.
An implementation that works for IO as the form monad can be found here.
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.
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.
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.