Next time I'd say this would be better in #news-and-articles, please. Thanks!

Will do sorry!

No stress, it's kind of an edge case

Hopefully not for long

Well, we've tried to keep #announcements to be new project or project version announcements, since so many people get notifications for it. It does definitely seem like there's lots of excitement about Athens; definitely a really cool project!

(thanks @U077BEWNQ -- I was just about to say the same since this is not a project/library release announcement)

I see you posted this in #jobs as well @UUY06DFL5 so it really should not be in #announcements as well.

Deleted

Thank you.

Something I've been wondering about since coming across this project - if I understand correctly, the compiler targets the VM? Is your end goal something like gccemacs's native-compiler? Did you consider the approach of plugging in to Golang's compiler internals and just generate ASTs directly from the code? That would require dynamic linking at runtime and I'm not sure if that's even possible

@UK0810AQ2 yes, the compiler targets the VM. I have chosen this approach to get a constrained execution environment decoupled from the language itself. This way it should be easier to optimize for runtime performance eventually and, perhaps even use the bytecode as IR for another stage that would produce machine code. Your idea with piggybacking on Go compiler crossed my mind but I’m not anywhere near this yet. One could imagine being able to dump the VM state as a standalone executable that would also contain the interpreter (compiler+vm) that only kicks in for the dynamic stuff. This is possible with bytecode alone but who knows where it goes in the future 🙂

Thank you. Do you think the decision to generate bytecode will hamper you in the future if and when you want to emit machine code? You might end up having to write your own compiler from scratch, which is a shame because Golang has a really good compiler. How constrained would you say the execution environment is given Golang has managed memory? Do you manage memory yourself? Do you feel like going a bit in depth regarding the VM's architecture?

The current VM is stack based, just a for loop with a big switch inside. It’s utterly slow as it performs runtime checks on everything - this serves mainly as an aid in development - it’s easier to debug when something goes awry. I will slowly turn it towards unsafe when the compiler matures enough that we can trust it. One thing to note is that each call frame has its own instance of the VM and the call stack is handled by Go at the moment - this is slow but will avoid GIL.

performance is my last priority as I want to get a correct interpreter as the baseline before I go into any attempts at speeding this up

as for compiling to machine code - when I get to it I will probably rely on an existing optimizing compiler anyway. In this case it’s much easier to translate a set of well defined bytecode instructions than it is to go from sexp level to target language/IR

Maybe you can target LLVM and re-use that toolchain, eventually

@U04V15CAJ either this or, like @UK0810AQ2 suggested, use Go compiler as a library and generate some Go SSA on the fly 🙂