Before you get started, watch this video that outlines how collaboration works in the Elm community.
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!
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.
Elm is great for data visualization in theory, and projects like elm-plot are beginning to make it great in practice!
Start by asking, “what kind of visualization do I need?” See if it exists as an Elm library. If not, create a view function that uses elm-lang/svg to display what you need.
From there, share your work and get feedback! API design is hard, and there are many folks in the Elm community that can help you refine and improve your designs.
Note: Resources like The Visual Display of Quantitative Information by Edward Tufte are great for learning more about the art of visual communication. It's not just about an API!
The search feature of package.elm-lang.org is quite rudamentary. 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:
- Explore full-text search. Does searching through everything in the docs give better results than just searching the name and summary?
- 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.
- 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 guide.elm-lang.org 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.
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:
- Be sure that code is getting optimized (but not deoptimized!)
- 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 reproducable part of the library. This way any potential changes could be informed by performance implications.
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:
-
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.
-
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.
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.
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 =
users
|> List.map .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 simplist plausible approach before diving into fancier techniques!
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!
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.
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.