Viewing profile — verdagon

Hi, article's author here (Verdagon, Vale's creator), and no, I'm just writing about someone else's language (Ante) that I thought was interesting. Ante is making some very intrigu…

I'm often skeptical of the desire to create a lot of passes. In the early Vale compiler, and in the Mojo compiler, we were paying a lot of interest on tech debt because features we…

This approach solves one borrow checking pain point (by allowing temporary mutable aliasing, even across function boundaries), but the post might actually be a bit conservative in …

Big fan of Verona, I love their memory safety approach as well. I wrote a bit about it in the Grimoire [0] too. IIRC they plan for the user to specify whether a region is backed by…

Yep, adding or removing an element would invalidate existing pointers to any other element in the hash table. This is generally regarded as a good thing if your elements are stored…

Great question! That's a big enough topic that I'd love to write a followup post about it. There's also a good thread on r/Compilers at https://www.reddit.com/r/Compilers/comments/…

Hey all, this is a post explaining a new memory safety model by my friend Nick Smith (original proposal at https://gist.github.com/nmsmith/cdaa94aa74e8e0611221e65db8e4... ) It was …

Great point =) That's true for a lot of languages (including Mojo too), so I should have said "non-owning reference" there. I'll update the post to clarify. Thanks for catching tha…

I can imagine a Rust-like language where we have move-constructors (in TFA), and every generated Future subtype is opaque and also heap allocated for us. I think the need for Pin c…

Good to see some more uses of linear types! Very few languages can use linear types, and their potential is huge IMO. OP shows the benefits of a linear RC that tracks references dy…

I've been looking into this, and I suspect that one actually needs surprisingly little to interoperate safely with Rust. TL;DR: The lowest common denominator between Rust and any o…

Just did, thanks for the suggestion!

Thanks! And yeah I get that a lot >_> You're always welcome to swing by the discord where I can give a less arcane explanation! ( https://discord.gg/SNB8yGH )

Hah I like this one! PS. Congrats! https://verdagon.dev/blog/easter-egg-notes

It could, but then that List would have to be linear itself, and then the program would make sure that you eventually drain the list and destroy each element. (One caveat is for li…

A really good question. In short, a linear List (or array, or hash map, etc) will only have two available destroyer functions: 1. drop_into(list, func): It consumes the list, calli…

I've got some weird plans for variants. Basically, we'd represent an enum as a non-heap-allocated sealed interface with a struct for each "case". Basically, think of a Scala case c…

Almost, but see the replies to IcyWindows' comment for why this unfortunately doesn't work in C++. Also, I would love it if C++ had a way to actually move. That would unlock all so…

You're exactly right, and that's kind of what Vale's `destruct` is, if you squint.

They almost work like this. std::move doesn't actually move an object; it leaves an intact instance... which we still don't know how to destroy (because its destructor is private).…