Forest: Bringing Elm to other domains than browsers

Request Feedback
1

I really enjoy Elm’s simplicity, and I would love to write applications outside of the browser in it. For example, many Node.js libraries just have simple functions that would be really nice to write in Elm. Or maybe even CLIs, that could be distributed via npm.

I totally understand why Elm does not support these environments. It clearly states that it is developed to be used for browser apps. That is one of its greatest advantages: it is very focused on that task, which streamlines everything and makes much of it look simple.

My idea would be to decouple the runtime from the language. How about having a functional language similar to Elm that would have a bunch of different runtimes available: One for the browser, one for Node.js, maybe one for LLVM. Of course, code would not be easily sharable between runtimes, and I think that’s ok. Node.js’s runtime might be modeled incompatibly, even for fundamental things like HTTP requests.

So I could imagine renaming the language to Forest and having tree names for the ecosystems around each runtime: Elm for the browser, Acacia for Node.js, Mangrove for LVVM… The language family, Forest, would ideally be exactly like Elm. Functional, type-safe, simple. Each runtime would provide a library that interfaces with its environment, just as the packages elm/http and elm/browser do. Acacia, for Node.js, could provide acacia/http, acacia/console, etc.

What this would necessitate is to decouple the language from the runtime and target language. I could imagine having a sort of intermediary, bytecode-like language that is passed to a dialect’s compiler for further processing, such as linking with the provided standard libraries and compiling to the target language. However, I have never touched compiler code, so I’m not sure how feasible this is and if it even is the right approach.

Forest as an “umbrella” language would bring Elm’s powerful simplicity to more domains than just the browser, while leaving Elm’s valuable focus on being a browser app language intact.

What do you think of this idea? Do you see any downsides or improvements? Do you think such a thing is feasible?

2 Likes
2

I also want to use Elm for everything.
But I think its very hard to actually do this. A new language feature would probably be great for one runtime, but bringing nothing to the browser.
That makes the language “larger” than it needs to be for browser use and Im afraid the simplicity we see today would slowly fade away ?? :confused:

3

I agree that would be a risk. But Evan actually managed to take a lot of features away, making Elm very compact. It feels absolutely sufficient to me, so I actually don’t think that there need to be significant new features at the language level.

In my imagination, most features would be at the runtime or library level. There, different paradigms might evolve that make the code hard to share between runtimes. But that’s not an issue to me. I could imagine Elm being very nice for simple CLIs, which currently is really tough to accomplish.

Rust seems to have a very nice story for CLIs as well, and I’m really intrigued by that language. However, by design it aims to control a lot of machine-level functionality, which means that we must concern ourselves with memory management. For many situations, I prefer trading some control for a gain in convenience, and in those situations, Elm would be awesome.

1 Like
4

I think elm/core could also be seen as decoupled, in the sense that it does not contain anything browser specific. Working from there, it should be possible to analyse the package repository, and find other packages that only depend on elm/core and re-use them too.

If elm/virtual-dom could be re-used, then a lot more packages can come across. There are others that can be re-used too, elm/json for example.

5

Yes, that would be great! The only risk I see, is that we try to hard to share packages, instead of tailoring an ecosystem around a certain task, such as browser or CLIs. But lots of things, such as elm/json will come in handy in many of them, so this is definitely a nice idea.

I think it would boil down to have some Forest packages, i. e. runtime independent ones, just as you stated. These might even be compiled directly to functions in other languages, such as JavaScript, because they would be pure functions.

6

Moving Elm to a different domain is a huge undertaking.

There is a big difference between a proof-of-concept or some hack solution and a solid alternative that can build a good reputation.

Elm is as nice as it is because Evan resisted the temptation of just providing some hacked together solution to an immediate need. He has invested a lot of time in the design of the language and of the main APIs.

I have not seen anyone doing the design work needed for another domain. I have not seen anyone even doing the research required prior to the design work for the domain. So… I guess you could say that work for other domains has not started yet.

Without someone actually investing the needed time, such expansions will not happen.

If you haven’t already, please read the post bellow in order to better understand what has worked so far:

7 Likes
7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.