I think the parent may be getting at the continuation aspect of effects? Effect systems make the stack a first class object you can reuse, I think a standard example is implementing a scheduler. I'm not familiar with your Bluefin library so maybe it already handles this:
effect Sched =
yield : unit -> unit
fork : (unit -> unit) -> unit
end
let mut run_queue = []
let enqueue t = run_queue := List.concat run_queue [t]
let dequeue () =
match run_queue with
| [] -> ()
| t :: rest ->
run_queue := rest;
t ()
let rec spawn task =
handle
task ()
with
| return _ -> dequeue ()
| yield () k ->
enqueue (fn () -> resume k ());
dequeue ()
| fork f k ->
enqueue (fn () -> resume k ());
spawn f
let run main = spawn main
let worker name steps =
let rec loop i =
if i > steps do ()
else do
print $"{name}: step {i}";
perform yield ();
loop (i + 1)
end
in
loop 1
let () =
run (fn () ->
print "main: starting";
perform fork (fn () -> worker "A" 3);
perform fork (fn () -> worker "B" 3);
print "main: forked workers, now yielding";
perform yield ();
print "main: done")
Ah yes, OK, I missed the point that the timeout is applied to the entire continuation, not just the part of the computation until the next await. Bluefin can't currently do that. I think I could make it do that, using the same implementation strategy as awaitYield (fork a thread, communicate through an MVar) but I wonder what the point is, given that Bluefin allows you to run the continuation at most once. Is the use case of "run the continuation in a modified environment (e.g. with a timeout)" really that compelling? Maybe it is! But I don't see it yet.
On the other hand, I don't see any difficulty with implementing a scheduler using Await/Yield. I don't think it needs access to the full continuation.
OCaml has full multicore support with algebraic effects now. The effect system makes things like async very nice as there's no function "coloring" problem: https://discuss.ocaml.org/t/ocaml-5-0-0-is-out/10974
But I don't believe the effects are tracked in the type system yet, but that's on it way.
The type system for effects is an ongoing research effort. For now you get unhandled effect exceptions at runtime.
With Multicore OCaml we gained thread sanitizer support and a reasonable memory model. Combined they give you tools for reasoning about data races and finding them. https://ocaml.org/manual/5.3/tsan.html
For a computer, text is a binary format like anything else. We have decades of tooling built on handling linear streams of text where we sometimes encode higher dimensional structures in it.
But I can't help feel that we try to jam everything into that format because that's what's already ubiquitous. Reminds me of how every hobby OS is a copy of some Unix/Posix system.
If we had a more general structured format would we say the opposite?
This reminds me of expect tests in OCaml[0]. You create a test function that prints some state and the test framework automatically handles diffing and injecting the snapshot back into the test location. It helps keep your code modular because you need to create some visual representation of it. And it's usually obvious that's wrong through the diff.
I will say I really love the outcome of a Nix development environment. Especially with nix-direnv having a reproducible build environment by doing git clone on any machine is amazing. NixOS has also saved my ass a couple times doing kernel updates on an old laptop, rollbacks are nice. Having consistent commands "nix build"/"nix run" is great. It's a universal build system that works across different technology stacks. Pain to setup, but bliss when it's working.
The bad part is the impenetrable errors and obscure configuration. Although, with the rise of LLMs I find it's not as bad. Getting a non-trivial flake.nix setup is much easier now. Could never remember the override system before, but can manage with Chat GPT haha.
You can project your programs into different views and add lots of metadata about the program and use that data in various contexts. Also extends to source control and other use cases. It looked really neat.
I buy into this theory, and the other one about consciousness being a step or two behind and fabricating some cohesive explanation for why you did what you did.
If you are unfortunate enough to experience some human body failure modes you can get a glimpse into this process. The cohesive "veil" breaks down and you realize there's more "you" than that voice in your head. The distributed nature of the brain/body peeks through.
This brings back memories. I ordered a NerdKit many years ago and one of the projects was making a scrollable LED panel using similar techniques you're describing:
I've noticed this too! It's especially bad after using discover weekly and liking a song or two, the shuffle then gets stuck on similar songs. It seems disabling "automix" in the settings returns the shuffle to be more like a traditional random shuffle.
