Skip to content
Branch: master
Find file Copy path
Find file Copy path
10 contributors

Users who have contributed to this file

@evancz @process-bot @Apanatshka @laszlopandy @jasonkuhrt @sharnik @nsocrates @joefiorini @romanzolotarev @avh4
207 lines (111 sloc) 13.6 KB

Before you get started, watch this video that outlines how collaboration works in the Elm community.

Elm Projects

For New Contributors

For Advanced Community Members

Again, it is very important that you watch this video and read these comments before diving into any of this stuff! Writing the code is definitely not the hard part on any of these!

Docs Previewer

When you are creating a package, it would be really helpful to be able to preview them locally. This would allow you to review them and make sure everything looks okay. You could also generate docs for your own non-package code and look at it locally.

Running elm-make --docs=docs.json will generate a JSON file with all the modules, types, comments, etc. The code for is basically some decoders and a view function to show that JSON. That means creating a tool to preview docs means making a little script to turn this JSON to HTML. If you want to get wild, it could be a local server that watches for changes to JSON files and updates the HTML as code changes.

In the long run, it would be ideal to have this just be a part of Elm Reactor out of the box, but that is step 17 of getting this going. Start with something small and manageable. Do not worry about sharing code in the optimal way. Do not worry about having a 100% visual match to the package website. Just make it! People will appreciate even the simplest version, and we can see what kind of coordination makes sense from there!

Markdown Parser

It would be great to have a markdown parser written entirely in Elm.

This is a hard project, so I recommend looking into jgm/cheapskate to see a very thoughtful and efficient implementation. The author is super smart and particularly knowledgable on this topic!

I would start by exploring with elm-tools/parser, but perhaps something more heavy duty will be necessary in the end.

Data structure evaluation website

Over time, the community will develop various implementations of data structures with different performance characterists. In my experiences in other languages, picking “the right one” is very time consuming. So the big goal here is to help people learn about these data structures and make the right choices for their application.

Say we have a couple Queue and PriorityQueue implementations, all with different performance characteristics. It would be wonderful to have a website that:

  1. Points people to great learning resources on immutable queues. What is a queue? What is a priority queue? Is it a tree structure? How does that work? Etc.

  2. Lets people race the implementations for various scenarios. Ideally folks could specify the size and shape of their data on the website and race based on that. If person A has ~100 items with Int priorities and person B has ~10000 items with String priorities, I would expect them to make the different choices.

  3. Maybe show graphs of performance vs. collection size so people can quickly get a feel for how data structures would work for their expected usage.

In the end, I think this would be an interactive website that approximates a college-level data structures course, but probably more fun! All the learning would be directed towards practical problems that folks actually have at the moment, and it will save them a bunch of time!

Some curration will be necessary to make this great. For example, there would have to be some process for including packages in these numbers. For example, if there is a package that is just has worse performance in all cases, it does not seem like a good use of time for people perusing this website. Ultimately, I think this project would need some coordination with core community members, so please talk about your work on the elm-dev mailing list to get feedback as early as possible!

Package Search

The search feature of is quite rudimentary. Community members have already created “type search” like this which is really cool, but I think we would benefit from a more traditional search feature as well.

Here are some ideas:

  1. Explore full-text search. Does searching through everything in the docs give better results than just searching the name and summary?
  2. Include secondary information in rankings. How complete are the docs? How many examples? How many infix operators? This would allow transparent mechanisms for incentivizing better package design and documentation.
  3. Many searches indicate a conceptual mismatch between JS and Elm. When someone searches for “components” the best outcome is that they find some documentation, not a package that claims that this is a thing. So it might be good to detect certain search terms and give structured information above the search results. For example, a link to the relevant parts of or some other relevant documentation.

Ideally this service can live on its own server. It would take in JSON and give out JSON. So if the search server goes down, it does not take down the package website. This makes it a great project because it minimizes technical coordination in the early phases.

I think it makes the most sense to focus on 1 and 2, and to not get hung up on the particular details of rankings. For any official use those details will need to be carefully tweaked, so perhaps the best system is one that makes it easy to analyze docs in various ways.


There is already a great foundation for WebGL with elm-community/webgl, allowing scenes like this.

From there folks are working on projects for terrain generation and loading 3D meshes.

I think we can make it really fun and easy to create 3D graphics with Elm, and it is a very deep topic. I recommend exploring topics like picking, entity-component systems, crazy shaders, etc. by digging into a project of your own and (1) seeing what you need and (2) sharing your observations in blog posts on /r/elm.

Profiling virtual-dom with V8 tools

The elm-lang/virtual-dom library is quite fast. It may be possible to do better though!

So the goal here is to get elm-lang/virtual-dom setup with v8-natives. This would allow us to:

  1. Be sure that code is getting optimized (but not deoptimized!)
  2. Know more about how much garbage is produced.

Perhaps certain functions need to be broken into smaller chunks? Perhaps values can be made more monomorphic? A great result would be writeups of what you observe when testing things by hand. If that is useful, it would be best to make these tests a reproducible part of the library. This way any potential changes could be informed by performance implications.

Improve Process Bot

There is this robot that goes around on Elm repos, trying to help issues and PRs go smoothly by letting people know about the contribution-checklist. There are two features that I think it would be great to have:

  1. Once a thread gets to 10 posts, process-bot would comment and tell people to close it down and (1) close it down and summarize the state of affairs in a new issue, (2) move the discussion somewhere else until it can be made more clear, or (3) keep talking in the closed thread until you decide to do 1 or 2.

  2. When a PR is opened, have process-bot check a list of people who have given contributors agreements. If they have given one, great! If not, give them a message telling them how to proceed.

The relevant code lives in this repo.

More Academic Stuff

There are a bunch of more speculative projects that it would be fun to look into, particularly if you are a student learning about compilers or programming languages. Please let folks know on elm-dev if you are looking into any of these as they touch on lots of core stuff and coordination is inevitable if things go well.

Type-Directed Autocomplete

The elmjutsu plugin for Atom does some very nice autocompletion based on type information. I think we can push this farther though. For example, if we see the following code:

longestName : List User -> Int
longestName users =
    |> .name
    |> ...

In the ... we know we want to get from List String to Int so we can suggest functions like List.length.

The best way to approach this problem is to try to implement the following function:

suggest : Dict String Type -> Type -> List Expr
suggest knownValues targetType =

type Type = Var String | Lambda Type Type | ...
-- simple representation of types

type Expr = Call String (List String)
-- in the simplest version, you suggest very minimal expressions
-- things like `List.foldl (+) 0`

By doing this, you decouple your work from other stuff. That means you can focus on making suggestions. If it goes well, integrating this with other things can be a separate project.

From there, perhaps we can rank suggestions based on which file or package they live in. Based on my experiences on Gmail, I am very interested to see how well we can do with simple heuristics. Assuming quality is good, this approach has many benefits over machine learning. For example, you can easily special case thing, you can tweak heuristics without retraining, and the results may be more predictable for users. Point is, focus on the simplest plausible approach before diving into fancier techniques!

In-browser REPL

Right now our REPL only runs on the command line. It would be amazing to have an in-browser REPL so we could actually see Html values and have a better UI for poking around expressions and values.

The most successful effort runs elm-repl on a server. This is quite handy, but I think we should take things like iPython notebooks as inspiration for the end goal.

I expect the early prototype would be a REPL for a simple lambda calculus (not connected to Elm at all) so you could test out the core UI ideas. From there, you would get in contact with community members who work on core tools and figure out what the path would be to bring it in. For example, it would be really cool if the time-travel debugger let you easily go into the REPL for any frame!

Explore Monomorphizing Compilers

The MLton project pioneered the “monomorphizing” compiler.

Normally functions like map : (a -> b) -> List a -> List b produce generic code that can work on any list, but if you happen to know that it is used as map : (Int -> Int) -> List Int -> List Int you could use a denser memory representation for the List Int, leading to quite serious performance improvements. Less indirection and less garbage generated!

This topic has a complex relationship to Elm because whole program optimization does not mix well with the kind of asset bundling you need to do in complex webapps.

The ideal result is documentation. What papers are relevant? What techniques are needed? Are there any Elm specific details or issues? This kind of thing can be shared as a blog post or mailing list post on elm-dev.

Explore WebAssembly

WebAssembly will be maturing over the next few years. Without a garbage collector, it is not viable for languages like Elm. In the meantime, there are a few questions it would be good to answer:

  • What are the facilities for representing UTF-8 strings? If you make it all from bit arrays and trees, we should do a “literature review” of how strings are represented in languages like JS, Java, Go, etc.
  • How does WebAssembly code interact with the DOM? What does that mean for Elm’s virtual-dom library?
  • How does WebAssembly interact with WebGL? What does that mean for Elm’s webgl library?

In all these cases, the ideal result is documentation that gets shared with elm-dev. Before making technical decisions and investments, certain big questions must be addressed. So it probably makes sense to do some prototyping, but the actual deliverable here is knowledge.

You can’t perform that action at this time.