> Though it seems like the language misses on popular nowadays generators, lambdas and coroutines. So I would say give it a plus on language design, and there is a space to grow.
Lambdas are actually the only way to define functions.
const f = {args
/* do stuff */
}
is just assigning a lambda literal to 'f'. You can also just pass them around, if you want:
use std
const main = {
var value = 42
thread.spawn({; std.put("hi from a thread. I captured {}", value)})
}
Coroutines are possible to implement as a library, and generators don't fit well -- there are iterators, though:
use iter
const main = {
var v = [1,2,3,4]
for p : iter.byperm(v[:], std.numcmp)
/* use permutation p */
;;
}
> What I think could be done better: compiler infrastructure / FFI.
You can already link to C, but writing the function definitons function definitions are painful. There's ongoing work to take Andrew Chambers' C compiler implementation, and extend it so that it can automatically generate the glue code.
We had a Summer of Cod[1] person working on it, but they dropped out due to lack of time.
> Lambdas are actually the only way to define functions.
Oh, missed lambdas, that's great!
> You can already link to C
I mean, only on Nix-es, only in Sys-V-like ABI. What if I'm under Windows? What if it's not Sys-V? What if I want Javascript (aka emscripten)?
My use case is game development, I could have a need to ship to wide variety of platforms (for some you don't even have publicly available specs, like PS3), and this platforms only provide C/C++ compilers. Why Myrddin compiler take a burden of supporting all C ABI's out there by implementing it's own asm code generation? Easier way out code be just generating higher level code like C or LLVM IR, and using libffi to implement FFI.
I would love languages like Myrddin to succeed, but let's be pragmatic, it is nearly impossible to support asm code generation with all C ABI's without having a full time team working on it. It is a huge time investment (not even speaking of financial investment connected to it). So I find it's hard for languages to get traction because they keep getting stuck inside Sys-V/Windows realm :( While something that compiles to C somehow magically just-work on everything, even web.
Oh, also, you can abuse closures to do generator-like things with captures, thanks to the way they're implemented.
use std
const mkincrement = {inc
var x = 0
/* No GC, so the upwards closures are explicit */
-> std.fndup({
x += inc
-> x
})
}
const main = {
var g = mkincrement(5)
std.put("{}\n", g())
std.put("{}\n", g())
std.put("{}\n", g())
std.put("{}\n", g())
std.fnfree(g)
}
Will output:
5
10
15
20
The trick is that the function state needs to be in the capture.
> Lambdas are actually the only way to define functions.
How does that work with regards to interacting with the function? If you see that function in a debugger or print it out, do you get just a generic "lambda" name or does it do some magic to get "f" when defined and assigned straight to a name?
> How does that work with regards to interacting with the function? If you see that function in a debugger or print it out, do you get just a generic "lambda" name or does it do some magic to get "f" when defined and assigned straight to a name?
It does some magic to get `f` when assigned straight to a name. The magic is pretty trivial.
> Though it seems like the language misses on popular nowadays generators, lambdas and coroutines. So I would say give it a plus on language design, and there is a space to grow.
Lambdas are actually the only way to define functions.
is just assigning a lambda literal to 'f'. You can also just pass them around, if you want: Coroutines are possible to implement as a library, and generators don't fit well -- there are iterators, though: > What I think could be done better: compiler infrastructure / FFI.You can already link to C, but writing the function definitons function definitions are painful. There's ongoing work to take Andrew Chambers' C compiler implementation, and extend it so that it can automatically generate the glue code.
We had a Summer of Cod[1] person working on it, but they dropped out due to lack of time.
[1] https://myrlang.org/summer-of-cod