*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 2020.programming-conference.or

But functions can now return outputs.

```
fn foo a: int -> result/eax: int {
result <- copy a
increment result
}
```

Project page: github.com/akkartik/mu#readme

Sources for the memory-safe language, now at 5kLoC: akkartik.github.io/mu/html/app

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
```

Show thread

*Update on the Mu computer's memory-safe language*

Basic language is done! Here's factorial. (Compare mastodon.social/@akkartik/1027.)

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: lobste.rs/s/pv8jpr/what_are_yo

(More details on the Mu project: akkartik.name/post/mu-2019-1. Repo: github.com/akkartik/mu)

Show thread

A brief timeline of the Mu computing stack

Jul 6, 2014: commit 0, tree-based interpreter for a statement-oriented language (github.com/akkartik/mu)

Jul 19, 2017: commit 3930, start of SubX machine code (akkartik.name/post/mu-2019-1)

Sep 20, 2018: started building SubX in SubX (mastodon.social/@akkartik/1007)

Jul 24, 2019: SubX in SubX done, commit 5461 (mastodon.social/@akkartik/1024)

Oct 2, 2019: started designing the Mu memory-safe language (akkartik.name/post/mu-2019-2)

Oct 29: started akkartik.github.io/mu/html/app

Show thread

I'll be in Porto, Portugal on Mar 24 to present a paper on Mu at the Convivial Computing Salon: 2020.programming-conference.or

Hoping for some great conversation and disagreements.

Show thread

*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.

akkartik.github.io/mu/html/app

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.

Show thread

*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: akkartik.name/post/mu-2019-1. Repo: github.com/akkartik/mu)

Show thread

*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: akkartik.github.io/mu/html/app

(More details: akkartik.name/post/mu-2019-2. Repo: github.com/akkartik/mu)

Show thread

The Mu compiler summarized in one page: akkartik.github.io/mu/html/mu_

More details: akkartik.name/akkartik-convivi

Repo: 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.)

Show thread

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 (akkartik.name/akkartik-convivi, section 4.4)

I spent the last 2 months switching all of Mu's implementation to this scheme. It was a tough time: lobste.rs/s/vcx5vu/what_are_yo. But now I know it works (with 10-15% slowdown), and Mu functions calling low-level libraries should behave unsurprisingly.

github.com/akkartik/mu

Show thread

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: akkartik.github.io/mu/html/app

Experience report: github.com/akkartik/mu/commit/

Also:
- I fixed a bug in the process: github.com/akkartik/mu/commit/
- 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.

Show thread

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: archive.org/details/akkartik-2

App sources: akkartik.github.io/mu/html/app

Repo: github.com/akkartik/mu

Show thread

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 (en.wikipedia.org/wiki/E._E._Cu)

Show thread

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: akkartik.name/akkartik-convivi. Repo: github.com/akkartik/mu)

Show thread

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:

akkartik.github.io/mu/html/app

This one is for you, @yrabbit 🙂

Old demo: archive.org/details/akkartik-2

Repo: github.com/akkartik/mu

Show thread

New demo: a text-mode RPN calculator built up from machine code

archive.org/details/akkartik-2

Inspirations:
* LoGlo (loglo.app/2020-06-16)
* Brief (youtube.com/watch?v=R3MNcA2dpt)

Unlike these, however, this version tries to hew to two principles:
* Show all the data (following spreadsheets and Joshua Horowitz; joshuahhh.com/projects/pane)
* Minimize interaction (following Bret Victor; worrydream.com/MagicInk)

Project page: github.com/akkartik/mu

Show thread

*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.

archive.org/details/akkartik-2

(More details: github.com/akkartik/mu)

[1] akkartik.name/post/mu-2019-1

Show thread

*Update on Mu*

My postfix language and its live-updating environment are starting to look promising. The environment can now expand multiple levels of function calls, laying out the state of the stack at each point. You can't edit a function at its call-site, but you can visualize its working in context.

archive.org/details/akkartik-2

(More details: github.com/akkartik/mu)

Show thread

*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.

archive.org/details/akkartik-2

(More details: github.com/akkartik/mu)

Show thread

*Update on the Mu computer*

My little prototype is starting to look like a shell: archive.org/details/akkartik-2

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: github.com/akkartik/mu)

· · Web · 1 · 4 · 8

@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:

- elv.sh/
- 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 xon.sh/
- Clojure 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!

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!