Still no type-checking or memory-safety, but we have partial support for arrays and product types. Still several sharp edges:
My todo list is growing. But work per item is shrinking. Hopefully there's an asymptote.
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 question: indexing arrays of non-power-of-2 element sizes.
Jul 6, 2014: commit 0, tree-based interpreter for a statement-oriented language
Jul 19, 2017: commit 3930, start of SubX machine code
Sep 20, 2018: started building SubX in SubX
Jul 24, 2019: SubX in SubX done, commit 5461
Oct 2, 2019: started designing the Mu memory-safe language
Oct 29: started http://akkartik.github.io/mu/html/apps/mu.subx.html
https://raw.githubusercontent.com/akkartik/mu/master/mu_instructions
It's not clean. Mu isn't a clean, well-designed language. Because it's designed to map 1:1 with x86, and x86 is not a clean, well-designed instruction set.
But this sort of 1-page summary of a compiler is something I've always wished I had. Something that doesn't tell you what to type out and then pretend you understand compilers.
Basic language is done! Here's factorial. (Compare with SubX.)
Still todo:
In other words, I'm about a third of the way there 😂 More detailed todo list.
(More details on the Mu project. Repo)
(Yes, in Mu you manually allocate registers. Mu will eventually check your allocation.)
Still no type-checking or memory-safety, but we now have local variables.
http://akkartik.name/post/mu-2019-2
https://github.com/akkartik/mu
It would be really nice to be able to avoid null pointers by construction. But providing opt-in null pointers would require option types.
Option types can be seen as a special case of sum types (tagged unions) but without needing an explicit definition for each unique type. I like Ceylon's generalization, which lets one use types like int|bool.
One interesting idea here is that anonymous unions are to sum types as tuples are to product types. The only wrinkle: it seems natural to refer to the variants of an anonymous union by type (you can't have int|int), but tuples by position ((int, int) is a common use case).
I'm also thinking about Rich Hickey's criticism of Haskell, that it should be possible to pass in an int to a function that expects an int|bool. That requires checking types based on their structure rather than their names.
But I'm reluctant to permit passing in a type point3D to a function expecting a point2D just because the member names are a superset. Perhaps structure should only be checked for anonymous types.
Should we be able to pass in anonymous types anywhere the language expects a type? In members of user-defined types? Any constraints seem surprising.
By now we're well in the territory of features that I'm not sure will have much adoption. Just because I wanted to provide clean concepts without surprising limitations.
I'm curious to hear where others would draw the line. How much of this seems reasonable, and how much excessive architecture astronaut-ism?