*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

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

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

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.

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


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: akkartik.name/post/mu-2019-1. Repo: 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: akkartik.github.io/mu/html/app

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

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

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.


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/

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

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

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)

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)

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:


This one is for you, @yrabbit 🙂

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

Repo: github.com/akkartik/mu

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


* 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

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


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

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

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


(More details: 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.


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

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

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.

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

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!

· · Web · 0 · 0 · 0
Sign in to participate in the conversation

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!