> I hope to see more "sugar" in languages to take advantage of calling out to other programs for help.
How about [1] and [2]?
My language has those because its first program was its own build script, which requires calling out to a C compiler. It had that before printing to stdout.
Turns out, that made it far more powerful than I imagined without a standard library. Calling out to separate programs is far better than a standard library.
Every unmarked function can do anything. If you add a new thing that functions can do, you assume unmarked functions can do it (even if they don't), and you add a trait for the negative.
If the goal is portability, Google pursued the idea of distributing cross-platform LLVM IR via PNaCl and ultimately abandoned it, because LLVM IR isn't really designed for portability.
Yao's concurrency will be explicit. You will not get concurrency unless you open a threadset and spawn threads. Yao scripts run in a single thread by default.
I focused on solving the concurrency problem because if it is solved, single thread code is solved as well.
Fair criticisms, John. I just want to address macros.
Yao has something like Rust's macros. They are called "keywords," because even the built-in keywords are implemented that way. (That is why Yao can just not have a `while` keyword.)
My Yao-based build system, Rig, uses keywords to implement a build DSL. [1]
How about [1] and [2]?
My language has those because its first program was its own build script, which requires calling out to a C compiler. It had that before printing to stdout.
Turns out, that made it far more powerful than I imagined without a standard library. Calling out to separate programs is far better than a standard library.
[1]: https://git.yzena.com/Yzena/Yc/src/commit/95904ef79701024857...
[2]: https://git.yzena.com/Yzena/Yc/src/commit/95904ef79701024857...
reply