Matthew Crews (Mar 24 2022 at 22:43): Matthew Crews (Mar 24 2022 at 22:43):I was previously an R developer and I miss the speed of development when it came to everything being an array and therefore loops were implicit. Would there be any facilities in Roc for this automatic looping or is that outside the design methodology of the language? Julia has some capabilities like this with their automatic broadcasting: https://julialang.org/blog/2017/01/moredots/
Derek Gustafson (Mar 24 2022 at 22:46):I think you're looking for List.map
Matthew Crews (Mar 24 2022 at 22:47):Perhaps. I'll have to consider if it covers all the scenarios I'm considering.
Derek Gustafson (Mar 24 2022 at 22:49):If not, I'd expect that there's another function that covers it. Explicit loops don't really fit into the functional programming style.
Matthew Crews (Mar 24 2022 at 22:49):Agreed. I only use them in low-level code in F#
Brendan Hansknecht (Mar 24 2022 at 22:51):I think that currently array programming is outside of the scope of the language, but a few discussions have popped up about support matrices and vectors. If they ever get first class support, of course a vector and an array are the same thing.
Brendan Hansknecht (Mar 24 2022 at 22:51):I don't think any serious design has been put towards it past telling people to look at futhark.
Brendan Hansknecht (Mar 24 2022 at 22:57):If anyone wanted to try to write up some more serious proposal, I am sure that the community would be open to evaluating it.
Brendan Hansknecht (Mar 24 2022 at 22:59):Though it might end up being something implemented in user space with abilities. Though it might hit weird dimensional issues with typing. Or force shapes to be sized at runtime (haven't thought into it a ton).
Thomas Dwyer (Mar 24 2022 at 23:20):Looking at futhark it seems doable. Would it be possible to have a platform which provides a map function (and others) that can interact with the GPU or revert to CPU should something not work? However, I don't know how or if using multiple platforms is possible. Would this mean it would require every function on vectors/the list to be provided by it? Originally i was thinking along the lines of list monad, but GPU usage is too appealing, albeit outside of any of my skills.
Brendan Hansknecht (Mar 24 2022 at 23:25):Would it be possible to have a platform which provides a map function (and others) that can interact with the GPU or revert to CPU should something not work?
Definitely possible. They can expose anything. They can even just pass a pointer to roc and have roc use it as an opaque type. Someone could theoretically make a platform that essentially exposes an APL interpreter to roc so that it can do array programming.
I don't know how or if using multiple platforms is possible
Not possible. This is actually one of the complications of roc. If I want to make a fast math library for roc that would use blas, there is no way to do it. It would have to be embeded in and wrapped up as part of the platform instead of being a library.
Maybe one day we could theoretically have some way of orchestrating this, but with roc's current embedding model, it is quite complex.
Would this mean it would require every function on vectors/the list to be provided by it?
Yes unless some where cheap enough to implement in raw roc.
Thomas Dwyer (Mar 24 2022 at 23:45):Is there any documentation on the current embedding model? I tried searching the repository, but couldn't find much. Even better, is there any documentation/comments about the current multiple platform problem?
Brendan Hansknecht (Mar 24 2022 at 23:54):So I don't think there is any cohesive single documentation. There is also a lack of documentation on platforms in general. Looking at examples is a good way to just view the platform/roc app split, but that doesn't really explain the linking model.
Brendan Hansknecht (Mar 24 2022 at 23:55):This talk also explains some of the platform/app split: https://www.youtube.com/watch?v=cpQwtwVKAfU&t=75s
but again not exactly linking and low level details, iirc
Brendan Hansknecht (Mar 24 2022 at 23:55):This is the surgical linker code, which will theoretically be what almost all roc code uses to link in the future: https://github.com/rtfeldman/roc/tree/trunk/linker
Brendan Hansknecht (Mar 24 2022 at 23:55):currently it only supports x86_64 linux.
Brendan Hansknecht (Mar 24 2022 at 23:56):It has a slim readme that at least lists the steps.
Brendan Hansknecht (Mar 24 2022 at 23:59):Even better, is there any documentation/comments about the current multiple platform problem?
Essentially the issue is that a platform is an executable. There is no way to merge two executables. It just doesn't make sense, they both have a main, etc.
Brendan Hansknecht (Mar 25 2022 at 00:04):We could theoretically link a native library as well as a roc library into a platform but that has a lot of complications. The main reason a Roc app can be linked this way is due to being a pure functional language. Anything that was impure and linked in this way could run into many problems around globals and state left behind between calls. On top of that, roc has an effect system to interact with a host, and that would also have to be used for any native libraries. That would likely couple the native library to how the host does effects and could break things if we return a native library effect to a host that doesn't expect it. So in the maybe doable but likely to have a lot of technical problems and making linking really slow.
Brendan Hansknecht (Mar 25 2022 at 00:05):And that doesn't even deal with the complication of roc needing to somehow know where an object came from so that it can deallocate it. If it came from the native library and we deallocate it with the host, we might get a segfault or some other bug.
Last updated: Jun 16 2026 at 16:19 UTC