> get into "unsafe" states on purpose

see, this seems like something that's nice to actually put into the types; a Ptr<Foo> is a real pointer that all the normal optimizations can be done to, but cannot be null or otherwise invalid, and UnsafePtr makes the compiler keep its distance and allows whatever tricks you want.

This only covers what's in https://wiki.osdev.org/Bare_Bones, but in Rust, right?

For each token generated, you only send one token’s worth between layers; the previous tokens are in the KV cache.

How's [0] or [1] for historical sources?

It's not surprising that Google doesn't turn these up, the golden era of this complaining was pre-WWW.

[0]: https://www.ee.torontomu.ca/~elf/hack/realmen.html [1]: https://melsloop.com/

Have you not noticed that the story you reference is so well know because... literally every single developer thinks people like Mel are crazy?

Mel or Terry Adams are the exception to the rule... Having that image of greybeards only come if you have never worked with one in real life, sorry you are biased.

What? Mel is regarded as deserving massive respect, not as crazy. If a developer thinks Mel is nuts, they are coming from a perspective I don't understand.

And yes, the shift to higher level languages like C, FORTRAN, etc., was regarded by some as pandering to the new generation that didn't want to actually learn programming.

With some truth, in my opinion. I think higher level languages bring huge benefits, so I'm not bemoaning their existence. But it still weirds me out when there's a professional developer that doesn't have at least a cursory knowledge of assembly. AI programming assistance (which I'm sure will be very different than today's 'vibe coding') does seem like a similar state change. I certainly don't object to it in principle, it will probably be a large productivity improvement.

But I'm sure that with it, there will be the loss of fundamental knowledge for some people. Like digital artists who never learn the properties of real paint.

how would you encode a program like

    function f<T>(x: T) { return x; }
    function g(x: number) { return { a: f(x), b: f(x.toString()) }; }

in sat?

if that's easy, how about length and f in:

    function append<T>(xs: list<T>, ys: list<T>) {
      return match xs {
        Nil() -> ys,
        Cons(hd, tl) -> Cons(hd, append(tl, ys)),
      };
    }
    function flatten<T>(xs: list<list<T>>) {
      return match xs {
        Nil() -> Nil(),
        Cons(hd, tl) -> append(hd, flatten(xs)),
      };
    }
    function map<T, U>(f: (T) => U, xs: list<T>) {
      return match xs {
        Nil() -> Nil(),
        Cons(hd, tl) -> Cons(f(hd), tl),
      };
    }
    function sum(xs: list<number>) {
      return match xs {
        Nil() -> 0,
        Cons(hd, tl) -> hd + length(tl),
      };
    }
    function length<T>(xs: list<T>) { return sum(map((_) -> 1, xs)); }
    function f<T>(xs: list<list<T>>) {
      return length(flatten(xs)) === sum(map(length, xs));
    }

hm-style inference handles polymorphism and type application without a complicated sat encoding

I wonder how well Proton would work for it...

It looks like colorForth runs in qemu or bochs according to documentation, so Proton/wine wouldn't be required.

Not counting, of course, the 30,177 suicides by American veterans in the wake of the global war on terror.

https://costsofwar.watson.brown.edu/sites/default/files/pape...

Beyond the Git history, is there any write-up of the different capability designs you've gone with?

I'm interested in implementing a safe low-level language with less static information around than C has (e.g. no static pointer-int distinction), but I'd rather keep around the ability to restrict capabilities to only refer to subobjects than have the same compatibility guarantees Invisicaps provide, so I was hoping to look into Monocaps (or maybe another design, if there's one that might fit better).

I summarize past attempts in https://fil-c.org/invisicaps

Test suites: https://github.com/riscv-software-src/riscv-tests

Formal model: https://github.com/riscv/sail-riscv

Are there even close to 2% of Debian users using a DEC Alpha?

popcon.debian.org reports 3 alpha installations and 261750 amd64 installations. Assuming comparable opt-in rates there are less than 0.002% of the users using alpha.

The other mentioned architectures hppa, m68k and sh4 are at a similar level.