neat VS mescc-tools-seed

It runs on plain C ABI, so you can just define C functions as `extern(C)`, just as you would in D. But you can also use `std.macro.cimport` to import C headers directly. Check out the Dragon demo, https://github.com/Neat-Lang/neat/blob/master/demos/dragon.n... :

    macro import std.macro.cimport;

Funny sidestory: The way my compiler ( https://github.com/neat-lang/neat ) used to build is, two years ago there was an initial compiler that was written in D. And every time you checked it out on a new system, there was a file with a list of breaking commits, and it would:

- git clone itself in a subfolder

Sure, but keep in mind it's pre-pre-alpha and the current released version is kind of outdated (ping me if you actually want to try it):

https://github.com/neat-lang/neat

This is more a D-like than a C-like, but it only breaks C syntax in areas where IMO C straight up made the wrong call, like the inside-out type syntax.

The thing I'm most proud of is the full-powered macro system, which is really more of a compile-time compiler plugin system.

A good example of a macro would be listcomprehensions: https://github.com/Neat-Lang/neat/blob/master/src/neat/macro...

You can tell it's just compiler code that happens to be loaded at project compiletime.

`compiler.$expr xxx` is itself a macro, that parses an expression `xxx` and returns an expression that creates a syntax tree that, when compiled, is equivalent to having written `xxx`. It's effectively the opposite of `eval`. In that expression, `$identifier` is expanded to a variable reference to "identifier".

So `ASTSymbol test = compiler.$expr $where && $test;` is equivalent to `ASTSymbol test = new ASTBinary("&&", where, test)`. (This shows its worth as expressions become more expansive.)

All in all, this lets you write `bool b = [all a == 5 for a in array]`, and it's exactly equivalent to a plain for loop. You can see the exact for loop at line 103 in that file. `({ })` is stolen from gcc; google "statement expression".

From here I found a reference to the Gash, Mes-M2 and stage0 projects, who's README.org references a nice wiki for stage0. The Wiki references a more expansive stage0-posix repo. From here, I finally got all the pieces to fit togeather.

Of course, reproducible builds will only give you security if you trust the compiler you're using to verify. Unlike traditional distributions, Guix packages are rigorously defined in terms of their dependencies all the way down to ~60 MB of bootstrap binaries. There has been a lot of cool work to reduce the initial binary seed size, and they are working to reduce this even further to a "full source" bootstrap which will make use of the stage0 project to bootstrap the entire OS from a small, auditable ASCII Hex -> binary program.

stage0-posix just gained initial support for RISC-V (64-bit). It starts with 392 byte hex assembler, 361 byte "shell" and bootstraps simple linker (hex2), macro assembler (M0). Then it builds cc_riscv64 RISC-V compiler written in RISC-V assembly and uses it to build simple C compiler written in C (M2-Planet). Then it builds a few extra utilities (cp, mkdir, untar, ungz, sha256sum, chmod)

I wonder if Brainfuck could be used for https://github.com/oriansj/stage0-posix ? It would not surprise me if there is no other language for which there are so many interpreters written in so many different programming languages. It is even possible to write a Brainfuck interpreter in Brainfuck, which can be verified. And there is also a Brainfuck interpreter written in x86-64: https://github.com/316k/brainfuck-x86-64 . It is a little larger than hex0_x86.hex0 , but not too much to make it hard to verify.

I'd argue the easiest to implement language is macro-assembly then the C subset known as cc_x86

https://github.com/oriansj/mescc-tools-seed