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

https://github.com/akkartik/mu

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

Repo: https://github.com/akkartik/mu

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)

Why do programming languages require us to specify what modules we use? I think that stuff is easy to deduce. Even in machine code.

https://archive.org/details/akkartik-2min-2020-06-07

cc @s_ol

@akkartik @s_ol If it's easy to deduce then we should let our editors add the import declarations themselves. Oh wait they already can.

@lunch You'd rather rely on a whole second tool parsing your code to do this, when your whole first tool could do it?

@akkartik If we're supposing that we don't want to write out import decls ourselves I'd rather not have the ambiguity of the compiler making a decision about it and have it explicit in the source code.