*Update on the Mu computer's memory-safe language*
Progress has been slow over the holiday season because I've been working on a paper about Mu for https://2020.programming-conference.org/home/salon-2020
But functions can now return outputs.
```
fn foo a: int -> result/eax: int {
result <- copy a
increment result
}
```
Project page: https://github.com/akkartik/mu#readme
Sources for the memory-safe language, now at 5kLoC: http://akkartik.github.io/mu/html/apps/mu.subx.html
Caveats: no checking yet, only int types supported.
*Update on the Mu computer's memory-safe language*
Still no type-checking or memory-safety, but we can now write any programs with int variables.
There's still no 'var' keyword, so we can't define local variables yet. But that's not insurmountable; just pass in extra arguments for any space you want on the stack 😀
```
result <- factorial n 0 0 0
```
*Update on the Mu computer's memory-safe language*
Basic language is done! Here's factorial. (Compare https://mastodon.social/@akkartik/102749590808384215.)
Still todo:
- user-defined types
- type checking and memory-safety
In other words, I'm about a third of the way there 😂 More detailed todo list: https://lobste.rs/s/pv8jpr/what_are_you_doing_this_week#c_5ymbsa
(More details on the Mu project: http://akkartik.name/post/mu-2019-1. Repo: https://github.com/akkartik/mu)
A brief timeline of the Mu computing stack
Jul 6, 2014: commit 0, tree-based interpreter for a statement-oriented language (https://github.com/akkartik/mu)
Jul 19, 2017: commit 3930, start of SubX machine code (http://akkartik.name/post/mu-2019-1)
Sep 20, 2018: started building SubX in SubX (https://mastodon.social/@akkartik/100779355103829305)
Jul 24, 2019: SubX in SubX done, commit 5461 (https://mastodon.social/@akkartik/102495274992610155)
Oct 2, 2019: started designing the Mu memory-safe language (http://akkartik.name/post/mu-2019-2)
Oct 29: started http://akkartik.github.io/mu/html/apps/mu.subx.html
I'll be in Porto, Portugal on Mar 24 to present a paper on Mu at the Convivial Computing Salon: https://2020.programming-conference.org/home/salon-2020#event-overview
Hoping for some great conversation and disagreements.
*Update on the Mu computer's memory-safe language*
Mu just got its first couple of non-integer types: addresses and arrays. As a result, the factorial app can _finally_ run its tests based on command-line args.
http://akkartik.github.io/mu/html/apps/factorial.mu.html
Addresses are accessed using a '*' operator. Arrays are accessed using an 'index' instruction that takes an address (addr array T) and returns an address (addr T).
Literal indexes aren't supported yet.
Open q: indexing arrays of non-power-of-2 element sizes.
*Update on the Mu computer's memory-safe language*
Still no type-checking or memory-safety, but we have partial support for arrays and product types. Still several sharp edges:
- can't index an array with a literal
- can't index an array with non-power-of-2-sized elements
- can allocate but not use arrays/records on the stack
My todo list is growing. But work per item is shrinking. Hopefully there's an asymptote.
(More details: http://akkartik.name/post/mu-2019-1. Repo: https://github.com/akkartik/mu)
*Update on the Mu computer's memory-safe language*
Arrays and product types are now done. Any remaining rough edges are working as intended 😄 Only hex literals, for example.
What's left? Actually making it safe.
Complexity outlay so far: 16k lines of code, but only 6.5k if you exclude tests. Tests get _very_ repetitive in machine code. Hopefully we won't need another 15k LoC.
Example program: http://akkartik.github.io/mu/html/apps/ex3.2.mu.html
(More details: http://akkartik.name/post/mu-2019-2. Repo: https://github.com/akkartik/mu)
The Mu compiler summarized in one page: http://akkartik.github.io/mu/html/mu_instructions.html
More details: http://akkartik.name/akkartik-convivial-20200315.pdf
Repo: https://github.com/akkartik/mu
(Brief update since there isn't much to report: I'm working on safe heap allocations as described in the paper. But it's slow going because of life and the need to unwind some past decisions.)
I'm back from a death march.
Mu is a safe language built in machine code, translating almost 1:1 to machine code. A key check is for use-after-free errors, using a second address type (http://akkartik.name/akkartik-convivial-20200515.pdf, section 4.4)
I spent the last 2 months switching all of Mu's implementation to this scheme. It was a tough time: https://lobste.rs/s/vcx5vu/what_are_you_working_on_this_week#c_pm4guj. But now I know it works (with 10-15% slowdown), and Mu functions calling low-level libraries should behave unsurprisingly.
I'm starting to build some simple apps in Mu, my memory-safe language that translates 1:1 to machine code.
Today I built a program to print a file to screen: http://akkartik.github.io/mu/html/apps/print-file.mu.html
Experience report: https://github.com/akkartik/mu/commit/b22fa8afd8
Also:
- I fixed a bug in the process: https://github.com/akkartik/mu/commit/583a966d3e#diff-938a2cc4d3707f088f06fabfc140a9c6
- I wished I already had clobbered-variable warnings.
- I wished I had type checks.
All in all, this language isn't ready for others yet. I'm constantly inspecting the code generated by the translator.
A new day, a new app
A text-mode paginator for text files. Think `more`, but no ncurses, no termbox, no libc, just Linux syscalls.
2-minute demo video: https://archive.org/details/akkartik-2min-2020-05-29
App sources: http://akkartik.github.io/mu/html/apps/browse.mu.html
It's amazing how much you can do layout-wise with just plain text. Pictured in this toot:
Alice in Wonderland by Lewis Carroll
Poems by e e cummings (https://en.wikipedia.org/wiki/E._E._Cummings)
My text-mode paginator for text files implemented all the way up from machine code now supports a tiny subset of Markdown syntax. Screenshots below.
The code is terribly ugly, and there are zero tests. But it did help flush out three bugs in Mu. Next steps:
- Build out the compiler checks I missed the most.
- Implement a fake screen and keyboard so I can write tests for this app.
- Throw the app away and redo it right.
(Background: http://akkartik.name/akkartik-convivial-20200606.pdf. Repo: https://github.com/akkartik/mu)
3 months ago I built a little prototype text-mode browser for a tiny subset of Markdown. Today it's a prototype no longer; it has fairly thorough tests. See how I write tests for the rendering in a language that maps 1:1 to machine code:
http://akkartik.github.io/mu/html/apps/browse/main.mu.html#L81
This one is for you, @yrabbit 🙂
Old demo: https://archive.org/details/akkartik-2min-2020-05-29
New demo: a text-mode RPN calculator built up from machine code
https://archive.org/details/akkartik-2min-2020-09-20
Inspirations:
* LoGlo (https://loglo.app/2020-06-16)
* Brief (https://www.youtube.com/watch?v=R3MNcA2dpts)
Unlike these, however, this version tries to hew to two principles:
* Show all the data (following spreadsheets and Joshua Horowitz; http://joshuahhh.com/projects/pane)
* Minimize interaction (following Bret Victor; http://worrydream.com/MagicInk)
Project page: https://github.com/akkartik/mu
Some tweaks to my text-mode RPN calculator built up from machine code, thanks to lots of helpful comments on the Future of Coding community (https://futureofcoding.org/community)
https://github.com/akkartik/mu/tree/main/apps/tile
Project page: https://github.com/akkartik/mu
*Update on stress-testing Mu*
I'm continuing to play with my prototype postfix calculator. Who knows, it may even become Mu's mythical level-3 language[1].
Today's video demonstrates function definitions that look different from concatenative languages, and a visualization for drilling down into function calls. All in an environment that updates as you type, built up from machine code.
https://archive.org/details/akkartik-2min-2020-09-27
(More details: https://github.com/akkartik/mu)
*Update on Mu*
This week in my postfix language and live-updating environment, I worked on a way to start from a raw computation, and extract functions from it as naturally as possible.
https://archive.org/details/akkartik-2min-20201020
(More details: https://github.com/akkartik/mu)
@akkartik
this is really nice. How do commands integrate with the Mu language and type system?
@s_ol It's just an interpreter so far, so they don't. Relationship is approximately like that between a C compiler in Unix and /bin/sh. Though I'm very interested in alternative approaches.
@akkartik
I see, so arrays, files etc. here are re-implemented at runtime for the interpreter.
I always thought having a sort of "universal type system" so that all languages ona system can interoperate on a level higher than files/streams would be nice. There's a couple of new shells trying to do this, I'll see if I can find them again in case you didn't see them yet.
On the other hand "universal type system" sounds like an idea built to fail...
@akkartik
here's the two I was thinking of:
- https://elv.sh/
- https://www.nushell.sh/
It might also be interesting to see how other shells that are tied to a particular programming language think about that integration. Off the top of my head:
- Python https://xon.sh/
- Clojure https://github.com/dundalek/closh
- CSH?
Most shells are already based on interpeted languages, but I think it's actually more interesting to make it work with static typing.
@s_ol Interesting idea, a statically but implicitly typed shell.
A 'universal type system' was in fact something I started out aiming at back in 2015. I still want it. SubX and Mu share a common vocabulary of types. I want all tools in the Mu computer to be aware of these types when browsing logs, etc. But it hadn't occurred to me to use them in the shell.
I don't think any of your links integrate with the underlying system. They're all dynamically typed interpreters. This is terra incognita!
*Update on the Mu computer*
My little prototype is starting to look like a shell: https://archive.org/details/akkartik-2min-2020-10-27
Promising in some ways, but I'm not sure how to support concurrency. Currently each operation completes before the next. I _could_ allow "pipe stages" to continue to share data after they drop file handles on the stack, but there are problems: how often we refresh, how we kill processes from past refreshes, how we visualize file handle contents.
(More details: https://github.com/akkartik/mu)