Damian Reeves (May 19 2024 at 19:59): Damian Reeves (May 19 2024 at 19:59):So I have just got into roc (looked at it some time ago and had no idea so much work had happened since I looked away).
I mentioned when I join Zulip that I am a maintainer for the Morphir project. Morphir provides a data format that allows you to capture your business logic and schemas in a pure functional data format known as the Morphir IR. Given that format (which we currently save as JSON), you are then able to generic code using a code generation backend, visualize your models (you can see an example of a complex model representing a regulation known as liquidity coverage ratio, LCR,), or interpret the model.
Elm helped our project to get started since our data format mapped to like 90% or more of Elm concepts. We have recently been looking to lean into our desire to support multiple front-end languages more explicitly in our tooling (you can do this now as you are a front-end if you produce the IR). Also Elm's lack of a packaging story, freeze on features , and not liking derivatives has bit us.
We have discussed perhaps forking Elm and making our own derivative language that could support our feature set, but looking at Roc its amazing as you have implemented many of the features we would want to implement.
So I'd love to experiment with using Roc as a front-end for Morphir, but I'd love to avoid having to write a Roc parser as there doesn't seem to be one. But since this is a different community than the Elm community and since Roc seems to pride itself in interop, I wonder if there would be any consideration in allowing users to plug into the Roc compiler to allow emission of their own custom files such as the Morphir IR.
I'd gladly be willing to contribute such a feature, though warning I am fairly new to Rust, but I have been diving into it with the intent of producing tooling in Morphir which resembles so much of what I already see in Roc.
Anyway, I've said a lot and look forward to feedback and comments. This language is amazing and I am excited to learn more.
Damian Reeves (May 19 2024 at 20:01):This is probably a better link to drop in here for more context around Morphir: https://morphir.finos.org/
Brendan Hansknecht (May 20 2024 at 00:05):I'm definitely keen to dig in and give some suggestions here, but will be travelling for the next few days. So hopefully will be able to loop back in a short bit.
Ayaz Hafiz (May 20 2024 at 00:41):Can you share what your IR looks like?
Ayaz Hafiz (May 20 2024 at 00:44):Depending on how much semantic information you need, there are a few IRs in the Roc compiler proper you could translate from. the most common one that existing backends translate from is called "mono", the AST for that IR is here: https://github.com/roc-lang/roc/blob/7e1a82f048f8ac77b07c7f03ffd30bb13f92edba/crates/compiler/mono/src/ir.rs#L1865. If it is feasible to generate your code from that, it may be worth trying to put up a branch to integrate with it. Because the language and its implementation is still very young, comitting to a public compiler API may be difficult, but I'm curious if integration at that stage would be sufficient.
Damian Reeves (May 20 2024 at 12:27):We need to have a better overview of the IR, but this should be a good jumping off point, the best docs for the IR end up being the Elm docs this page links to: The Morphir IR | Morphir (finos.org)
Richard Feldman (May 20 2024 at 14:32):thanks for the interest! :smiley:
so the current plan is that for the indefinite future, Roc should support compiling only to machine code and to WebAssembly. We get asked about compiling to JS and to BEAM decently often, and to JVM less often than that, but I think the right design is to focus on a narrower set of compilation targets
Richard Feldman (May 20 2024 at 14:33):part of the reason for this is that the broader the base of targets we support, the harder it is to figure out what the performance characteristics of any given piece of Roc code will be, especially things shared across targets
Richard Feldman (May 20 2024 at 14:34):another factor is that if we commit to supporting the target, that will end up being an indefinite source of complexity and work to maintain support, even if it ends up only being used by a small fraction of the Roc community :sweat_smile:
Richard Feldman (May 20 2024 at 14:34):so I think if I were in your position, personally I would just fork the Roc compiler so you can try it out, and see how it goes!
Richard Feldman (May 20 2024 at 14:34):(as in, fork with no plan to upstream the changes)
Richard Feldman (May 20 2024 at 14:35):there are plenty of people in Zulip here who know how the compiler works, so we can help you out with where to put things if you get stuck
Damian Reeves (May 20 2024 at 14:36):So if I were to fork the compiler and call the CLI tooling "morphir" for example... is that allowed/correct?
Damian Reeves (May 20 2024 at 14:36):I totally get your position and it makes total sense.
Richard Feldman (May 20 2024 at 14:41):yeah, absolutely - go for it!
Richard Feldman (May 20 2024 at 14:42):(while respecting the license of course!)
Damian Reeves (May 20 2024 at 14:45):Awesome... I'm looking forward to working with Roc and learning more about the compiler and ecosystem.
By the way I love the Abilities approach as well as platforms... I only begrudgingly recently decided to learn Rust, since WebAssembly is most mature in Rust, but F# is my favorite language and I come from a Scala and Elm background as well. Roc is closer to what I wish Elm was.
Last updated: Jun 16 2026 at 16:19 UTC