tekknolagi

I haven't manually checked every case but it's normally folded into the load or shift or whatever and completely erased

This is so great. I've been watching the project develop and it's really neat to see this milestone!

We used memcpy everywhere in our runtime and after the 10th or so time doing it, it becomes less awkward.

I'll get back to this in more detail soon, but I did have lambda expressions in my blog post...

See also: retool

Taking a look now. A couple of questions:

* Why give literal ints their own temporaries? * Why not support lambda expressions? Is it tricky in this approach or just accidentally missing?

Please show this gist. I would enjoy linking to it

Funnily enough, both CPS and SSA are US government services

To be clear, I am not Taylor and I did not come up with scrapscript! That website belongs to him and I'm just a random guy on the internet who emailed him and built an implementation.

The way I think about it is kind of like software versions. Say you want to do some kind of reproducible software. You can write that your software depends on jazzinator==3.0.0 but that's kind of unsatisfying because it relies either on tools or people to make sure that versions are immutable. It also relies on jazzinator to specify its own dependencies pretty strictly. So maybe you end up inventing the concept of a lockfile to partially solve that problem, but you still have the issue of relying on a third party to not change things up on you.

However, if you can address a library by a name that is computed from its code (a hash), things get interesting. You end up with this tree/DAG of dependencies where every dependency is immutable--you can't change the code without also changing the name. It's a Merkle DAG like Git. You do lose the ability to say things like "above version 2.5"... sort of.

If you also build a ref or tag system (similar to Git refs), you can kinda do normal style versioning on top of this content addressable world. But again, that relies on someone or something (maybe your hash-based store) to keep a map point-version names to hash names.

The other thing that's interesting with scrapscript in particular is since everything is addressable, you can use (sort of implicitly import/download) any value from any other program in a repository readable by you. But no scrapscript implementation fully does this yet, as far as I'm aware. For a fully working system, check out Unison.

Now that I'm back at a computer:

* https://bernsteinbear.com/blog/scrapscript/

* https://bernsteinbear.com/blog/scrapscript-baseline/

* https://bernsteinbear.com/blog/scrapscript-tricks/

* https://bernsteinbear.com/blog/type-inference/

* https://bernsteinbear.com/blog/row-poly/

and the repo for the main implementation: https://github.com/tekknolagi/scrapscript

See my other blog posts and GitHub if you would like some more!

No, and in fact internet searching for continuation-passing style stuff is quite tricky for this reason :(

GraalVM tends toward open core. They have entire test suites and test tools that are internal-only that make developing it kind of difficult.

Thank you for your feedback. I'll take that into consideration for my next blog post and compiler.

~~It didn't work; PyPy moved away from partial evaluation years ago~~

Sorry, I think I was responding to completely the wrong comment. I would also like a more general-purpose tool for writing fast programming language implementations

There is significant warmup required, which is not good for most programs. Deegen's approach is very promising for interactive use or other situations that require low latency.

It is very exciting to get a multi-tier VM from just bytecode encoded version of VM spec.

No, they also compare JIT to JIT and theirs is 30% slower. But it's only a baseline JIT and they'll have optimizing soon (tm).

Oh? Which python runtime?

They are extraordinarily different languages and runtime systems.

See also https://github.com/nakst/gf

Please do! I would love to read it and link to it!

The man, the myth, the legend! Ok, so for extensible records: I don't have a good intuition for why the record objects would have to keep around the shadowed (hidden/duplicate) fields at run-time. Do you have a motivating example for that? Also entirely possible I missed it in the paper

(I'll check out the new paper later - thank you for the link)

I thought a lot of b(+)tree advantage was in bigger-than-RAM something or other for large databases and these benchmarks seem relatively small in comparison

They have gotten much better about that recently and it's much much more compatible now.

I did not specify the integer size. It could be arbitrary precision like Python.

Yes; they're small enough that it's reasonable

Bundle them into your project. Commit them into your source control

    #include "fenster.h"
    #include "microui.h"

(see main.c and Makefile)

Probably yes, but it wouldn't be upstreamable into fenster. A Wayland impl would at least double the size. I'm vaguely looking into it anyway. Feel free to file an issue

I originally wanted to port dear imgui to fenster but that looked difficult and microui already had a very straightforward little bytecode to implement