UncleEntity

> Which makes me wonder: what’s the appeal of PEGs or parser generators now?

I just had the robots write a PEG parser generator...

Which can do analysis on the grammars which, I suspect, a hand (or LLM) written one can't do so you don't end up chasing infinite recursion, dead rules and whatnot. It also got shoehorned into the regex engine (https://arxiv.org/abs/1210.4992) for my toy Java 1.0 compiler to loop back to TFA.

For my APL interpreter they had to do the 'handwritten' parser (a Pratt parser a sibling comment brings up) as you need to combine parsing and evaluation since there's no way for the parser to tell what it's looking at because APL syntax is just weird.

Horses for courses, as they say.

I'd like to see the UCLA study which showed that in states that legalized marijuana, bankruptcies and credit card delinquencies increased about 25%.

Admittedly, I didn't read the whole article but I didn't see anything about banning social media and/or putting pot stores on every corner to compete with the liquor/tobacco stores. Seems like something they would have put in the beginning to draw the reader in, dunno?

What I do know from living on this planet for over half a century is that gambling and alcohol and certain drugs are very addictive and have the tendency of ruining people's lives. Pretty much common knowledge at this point, one would have thought...

The problem I've been having is the LLM's are super dodgy, not even ten minutes ago the 'solution' to a proof failing was to disable that check in the static analysis harness so the tests pass since their first try (with a counter example and lemma from the literature in hand) didn't fix the issue.

Maybe it's an issue because it controls both sides of the fence and can change things willy-nilly when it thinks I'm just watching the youtubes but I haven't been able to find a another way to do this so, here we are...

I've been poking at a C version of this (https://github.com/dan-eicher/javelina) which would be interesting to benchmark against as it does a similar tail-calling dispatch mechanism. Plus copy-and-patch JIT but that probably only works on x86-64 as that's the only place I've ever tested it. The main differences from a brief skim of TFA is mine doesn't have any fallback (so non-tail calls will blow up the C stack) and the function calls always go through the trampoline so the VM doesn't have to care if it's calling JIT or interpreted code which, I'm assuming, your function pointer embedding thing is designed to optimize away.

And the JavaCard firewall algorithm would be an interesting non-spec addition to a wasm VM which is running code you really, really don't want to escape the sandbox. Something to look into for inspiration on the subject, perhaps? Not sure if there's any sort of proposal for sandboxing these things as I just took the spec file and implemented it using the dodgy weasels where it was mainly to see how far they've come with no real plan to use it for anything so kept it strictly to what the spec said a wasm interpreter needs to do.

Anyhoo, didn't really realize there were so many different projects doing the same thing, kind of interesting, actually...

>> I was curious why you swapped over to a register based VM

Not the OP but there are real performance benefits, I've been poking at a wasm VM and it has two jit backends where one is pure copy-and-patch while the other caches the locals in registers using the function args + copy-and-patch and there is a significant performance gain just from that alone. A push/pop from a stack is fairly expensive while the register caching keeps things in the CPU's happy place. The smallest gain was ~2x over the interpreter on memory bound tasks while the largest was ~20x on math heave kernels. Admittedly, the interpreter isn't the fastest thing ever as its one and only goal is conformance with the spec to use for differential testing but the difference between the the two jit levels are somewhere in the neighborhood of 1.5-5x depending what the code is up to.

The three biggest performance gains, from the random benchmarks, are quality of the bytecode out of the compiler, the jit itself and register caching from what I can tell from the fancy chart I had Claude make and a good squint. Tail-calling would be somewhere on that list too but I can't measure that as all the opcode do the tail-calls between each other as that's just how it was all put together, the code the interpreter runs is the same code the copy-and-patch jit stitches together as they are both generated from the same DSL. Which is also the biggest cost with the register caching as the code template file grew from tens of kilobytes for the 407(?) wasm opcodes to ~3MB for all the specialized ones to pass the locals in eight args but that's really just a binary size thing, the stitched together functions just pick and chose the ones they need.

Long winded way to say CPUs like when you keep things in registers, I suppose...

I thought this was just a thing until I moved from Cal to Arizona and people would get really mad about it until I asked someone at work and learned it's illegal.

My first motorcycle was fast enough to get out of the way of stupid drivers (and be fun) while my last one was so fast it still amazes me to this day that I'm still alive. Apparently it was amateur raced with all the things that entails, which is probably why I didn't die as it was so obnoxiously loud people knew there was a motorcycle around them so I couldn't really hide in their blind spots, not that I would ever do that because that's a quick way to get a free ride to the ER.

$2500 for a vehicle which could most likely top out around 200 mph probably wasn't the smartest purchasing decision I've ever made. The only smart thing I ever did was there was always something suitably wrong with it I never took it out into the desert to see what the real top speed was.

My Fiat 500 has the same size engine and keeps me out of trouble. And around the same MPG...

Yeah, that only works if they follow the plan (they don't), actually write the tests first (they don't) and don't silently defer anything which doesn't have a test written as "speculative without a use case".

Or just write tests to match the buggy code after you call them out for not writing tests.

I mean, the struggle is real...

No matter how weasel-proof you make the plans they are much better weasels and just do as little as possible and "the test not written is the test which never fails." There's a certain amount of zen to them.

Yeah, I used to work with a ton of “unhinged” people willing to take risks because it was the literal job requirement, being willing to jump out of a perfectly good airplane behind enemy lines, yet was completely optional as one has to both volunteer for jump school and could always refuse to jump with no real punishment... well, as long as you did the jump refusal on the ground and were willing to go wherever they decided to reassign you (Korea).

Even they didn't expect anyone to work seven days a week forever, we trained hard and were given plenty of downtime so nobody went (too) crazy.

Seems like they're trying to go back to the days of serfdom without the Sundays off bit...

> Native interop with JS objects on the JS GC heap isn't supported as well.

Isn't that what the i31 type is for, that extra bit is a tag for...something, native GC'd object perhaps? Not so clear on that myself as Java's object model (minus synchronized) slots in perfectly so my Java 1.0 -> wasm compiler doesn't need it but that's my limited understanding of what it's for.

I just have them write the tools to write the DSL's to do the thing then (most of) the sloppy code stays in the generator and if all the different things depend on each other they don't go stale and whatnot. And let them design the DSL themselves for whatever task so it matches their 'internal concept' of how the things work.

Worked out pretty well so far but not really practical unless your goal is to make the tools to make the DSLs to make jitting VMs -- https://github.com/dan-eicher/BBQ kind of snowballed from "let's parse some binary files" to a way over the top toolkit for playing around with this stuff but, it's fun...

I mean, I got them to 100% using the official conformance suite on my copy-and-patch jit compiler/interpreter WASM VM...

Saw that Salt Language article a day to two ago on how they do the static verification as part of the compilation process (or whatever they really get up to) and that's next on the agenda, tried that with a JavaCard VM I was poking at as its 'computation space' is much smaller but that was too much for my poor little laptop to handle but, apparently, this Salt thing is much different and actually tractable so, we'll see, still working out the details.

What I suspect is this 17% is the exact sub-set it needed to hack together to make the goal (running some example website) a reality as this is what those dodgy weasels do if you let them. Then you get to spend 200x the time to fill in the rest of the "speculative features deferred due to no real consumer" on top of whatever dodgy system they made up, which is usually whatever is easiest/closest to the literature instead of the actual intended design. Lots and lots of fun to be had doing the full-pipeline refactors to add that last 2% which need support from tip to tail.

It's all in good fun, though... probably?

Fairly certain all those have "acts of congress" attached to them. I mean, it used to take a constitutional amendment to make something illegal but now we have tons of agencies responsible for regulating all the things.

Plus, they're relying on the "math is a weapon" law to ban "export" of the models.

I was playing around with stuff trying to get Claude produce a JavaCard VM with the idea that the VM was hand written from the spec with a separate, independently produced, spec file used to generate tests for ESBMC to verify so an identical bug would have to exist in both to make it through. Worked out pretty well, found a few bugs in both projects, but my poor laptop can't handle the full 32-bit space so that part never got the full verification -- 16-bit, rock solid though.

Then I really got serious about the yak shaving and, well, am probably in need of an intervention as I don't get Claude to write a VM but to make the tools to generate a VM from an assortment of DSL and that has snowballed a bit as I really liked shaving yaks before the daffy robot revolution.

--edit--

Almost forgot, I tried that with the little less dodgy banned Claude and the wasm standard it wrote a python script to parse the spec pdf, the official bytecode implementation in OCaml (or whatever) and generate a TOML file (Claude loves the TOML) to generate the type headers and for cross-referencing in the other tools. Was so impressed I just let it go on its merry way and it did the deed.

Sure, but the attached chat rooms were pretty handy, I used to like to download bootlegged concerts back in the day, to find new ones you've never heard of.

Plus, always fun to get laughed for mistyping The Almond Brothers Band at 3am...

"If you have a question look in the specification for the answer and don't just guess" seems a fairly important thing to remember for more than a couple of minutes...

I think the problem is they take the shortest path to the goal ...which may or may not coincide with what you have planned. Oh, and generally think instructions are merely suggestions and what you really want this this totally different thing and not the one in the plan you handed them plus, as a stoke of good luck, this other system is a lot easier to implement as well.

I mean, I spend more tokens having them clean up all the places they didn't follow the the plan (if I catch it) or implementing what came out of a 'complete and tested' previous plan where they just stop as soon as all the pathetic new test pass and you discover half of it isn't even there when trying to implement the next thing on top of it.

Though... I have been conducting an experiment, of sorts, where we've been cooking on these fairly complicated projects and I don't ever touch a single line of code, just yell at them a lot, and with suitable amounts of marijuana (they are very frustrating most of the time) it's been going pretty well. I also helps that they need to explain what they're doing to somebody fairly-baked -- maybe not such an HR friendly plan?

> Control and effects are different things...

I've been quite smitten with Destination-Driven Code Generation and its separate data and control destinations feeding through to the sub-trees letting everyone know what's expected to happen to the data they're computing and where to go next. Makes a super-simple CPS converter as destinations == continuations and I can feed the CPS IR straight into a Click-inspired optimizer to do the things. It's actually fairly close to the design from TFA just based around continuations and whatnot instead of a SSA IR.

> but the tail calls are integral to the function of the interpreter

Not really, a trampoline could emulate them effectively where the stack won't keep growing at the cost of a function call for every opcode dispatch. Tail calls just optimize out this dispatch loop (or tail call back to the trampoline, however you want to set it up).

Yeah, Clang's musttail and preserve_none make interpreter writing much simpler, just make yourself a guaranteed tail call opcode dispatch method (continuation passing style works a treat here), stitch those together using Copy-and-Patch and you have yourself a down and dirty jit compiler.

> Now do it without those pre-written tests

That's probably the most important thing, actually. I've tried my hardest to get Claude to build an APL VM using only the spec and it's virtually impossible to get full compliance as it takes too many shortcuts and makes too many assumptions. That's part of the challenge though, to see how far the daffy robots have come.

> ...and the right-to-left evaluation logic.

The evaluation order doesn't matter as much as you don't really know what kind of function/operator you have at parse time so have to do a bunch of shenanigans to defer that decision until runtime while still keeping it efficient. Kind of fiddly to get right but once it works, it just works.

Claude and me (and a ton of decades old research) pretty much figured out all the complications in the APL parse/eval stack (https://github.com/dan-eicher/AiPL).

Pivot to where the stupid money is being thrown around seems like a perfectly reasonable business plan.

One of my experiments was to have Claude write a VM and then generate a verification harness (using a DSL) for it to ensure it was correct with the theory being the same bug would have to exist in the test suite, the static verification and the VM for it to sneak through. Found a few bugs in the verification library and some integer overflows in the VM then it became too much for my poor little laptop to run without cutting some important corners.

It's not an abstract thing they can't do, you just have to tell them to.

I find it as an interesting experiment to find the limits of what they can do.

Like, I've had it build a full APL interpreter, half an optimizer, started on a copy-and-patch JIT compiler and it completely fails at "read the spec and make sure the test suite ensures compliance". Plus some additional artifacts which are genuinely useful on their own as I now have an Automated Yak Shaver™ which is where most of my projects ended up dying as the yaks are a fun bunch to play with.

My project over the last week was to get the robots to train a neural net to learn the "303 thing", hasn't gone well at all.

The first one sounded like it was being played on a blown out speaker after it got run over and the second attempt sounded like it was going through a $20 pawn shop guitar pedal that got left in the rain which lead to the 'oh, you wanted the neural net to learn the 303's filter section? My bad, I just made some random stuff up as an approximation...'

The worse part is there's still compute credits left over from the initial ten bucks so we just have to try again...

Yeah, back during Trump's first term I was hoping Congress would rein in executive power a bunch as he is prone to do stuff like this, didn't turn out that way unfortunately...

Now the main constraint on executive power seems to be due process and habeas corpus.

The problem I run into is the propensity for it to cheat so you can't trust the code it produces.

For example, I have this project where the idea is to use code verification to ensure the code is correct, the stated goal of the project is to produce verified software and the daffy robot still can't seem to understand that the verification part is the critical piece so... it cheats on them so they pass. I had the newest Claude Code (4.6?) look over the tests on the day it was released and the issues it found were really, really bad.

Now, the newest plan is to produce a tool which generates the tests from a DSL so they can't be made to pass and/or match buggy code instead of the clearly defined specification. Oh, I guess I didn't mention there's an actual spec for what we're trying to do which is very clear, in fact it should be relatively trivial to ensure the tests match for some super-human coding machine.

All I hear about is how this is the 'shape of things to come' with regards to the AI bubble while nobody seems to care that France just told all the gov't agencies to stop using their stuff.

Losing out on EU governmental contracts seems to me to be somewhat of a big deal and the France thing is just maybe the first move in that direction.