I don’t see the point (other than coolness for the sake of coolness) of trying to recreate a vector-based, inherently imperative language on a virtual machine that does not lean itself to imperative programming in general. BEAM primitives do not include tools to deal with mutability, at all, and array support is non-existent in BEAM [1]. Compiling a vector-based language into BEAM is just combining the worst of both worlds.
A more viable approach would be to extend BEAM itself to include efficient mutable vectorized operations, but it’s still unclear who would need a hybrid of Octave and Erlang and why.
Maybe just for intellectual challenge like with the demoscene.
Alternatively with wild speculation, you have a legacy application in Erlang but no library or language for easily expressing or checking certain types of solutions. You build something to handle that which integrates with legacy app. Ive seen that kind of thing done with C, Java, etc.
It would be interesting to see some kind of cross-section between apl and a language like translucid . So instead of having mutable arrays you have multidimensional streams.
Does it need to be truly mutable? I mean, if we are talking about a BEAM language as APL-ish as Erlang is PROLOG-ish, then we’re not really talking about underlying semantics at all.
On hn, the author of the article mentions about he’s far more interested in a good way of expressing set operations and business rules in those terms, rather than writing a high performance array processing language for Erlang.
Does BEAM have good FFI support? Generally speaking, if you want to make matrix operations efficient, you first make them possible with a friendly front-end and then you replace the backend with calls to existing hyper-optimized FORTRAN libraries, like both numpy & julia do. It means breaking out of the VM though, & potentially breaking some of Erlang’s guarantees.
Erlang has ways of calling into C, but those are generally considered something to be careful of, because they can block the scheduler, though NIF’s marked as dirty seem to be able to trade off a little bit of performance to get those scheduling properties back.
For the use-case that the poster was thinking of, however, I think it might make more sense to start by backing the arrays with Erlang binaries, but I could be wrong. I’d certainly be interested to see what it’d look like.
I don’t see the point (other than coolness for the sake of coolness) of trying to recreate a vector-based, inherently imperative language on a virtual machine that does not lean itself to imperative programming in general. BEAM primitives do not include tools to deal with mutability, at all, and array support is non-existent in BEAM [1]. Compiling a vector-based language into BEAM is just combining the worst of both worlds.
A more viable approach would be to extend BEAM itself to include efficient mutable vectorized operations, but it’s still unclear who would need a hybrid of Octave and Erlang and why.
[1] “Arrays are implemented as a structure of nested tuples.” – https://stackoverflow.com/questions/28676383/erlang-array-vs-list
Maybe just for intellectual challenge like with the demoscene.
Alternatively with wild speculation, you have a legacy application in Erlang but no library or language for easily expressing or checking certain types of solutions. You build something to handle that which integrates with legacy app. Ive seen that kind of thing done with C, Java, etc.
It would be interesting to see some kind of cross-section between apl and a language like translucid . So instead of having mutable arrays you have multidimensional streams.
Does it need to be truly mutable? I mean, if we are talking about a BEAM language as APL-ish as Erlang is PROLOG-ish, then we’re not really talking about underlying semantics at all.
On hn, the author of the article mentions about he’s far more interested in a good way of expressing set operations and business rules in those terms, rather than writing a high performance array processing language for Erlang.
Makes sense.
Does BEAM have good FFI support? Generally speaking, if you want to make matrix operations efficient, you first make them possible with a friendly front-end and then you replace the backend with calls to existing hyper-optimized FORTRAN libraries, like both numpy & julia do. It means breaking out of the VM though, & potentially breaking some of Erlang’s guarantees.
Erlang has ways of calling into C, but those are generally considered something to be careful of, because they can block the scheduler, though NIF’s marked as dirty seem to be able to trade off a little bit of performance to get those scheduling properties back.
For the use-case that the poster was thinking of, however, I think it might make more sense to start by backing the arrays with Erlang binaries, but I could be wrong. I’d certainly be interested to see what it’d look like.