leonardool

I've been working on a similar (ish) project for a while: Ribbit (https://github.com/udem-dlteam/ribbit). Supports a full R4RS REPL (with tail-calls) in the same sizes as Lispy (8Kb for JavaScript and 6.5Kb for x86)!

  Location: Montréal, Canada
  Remote: Yes
  Willing to relocate: For the right opportunity
  Technologies: Compilers, virtual machines, Scheme, LLVM, Python, language design, language runtime, garbage collection
  Résumé/CV: https://oestoleary.com/leonard_oest_oleary.pdf
  Email: See website (https://oestoleary.com) or résumé

Previously a Production Engineer at Meta, I have spent the last ~5 years building compilers and computer languages. I recently submitted my Master’s in compiler design, with research on memory management, garbage collectors and virtual machines published at PLDI and ICFP workshops.

I'm passionate about anything touching a compiler. Here are some projects I'm particularly proud of:

- Lead maintainer of Ribbit, a highly portable and compact Scheme compiler supporting over 25 target languages (including C, x86, POSIX-Shell, Haskell, and OCaml): https://github.com/udem-dlteam/ribbit

- A new garbage collector algorithm (that can collect cycles immediately), implemented in C https://dl.acm.org/doi/10.1145/3735950.3735953

- A merged C++ patch to the LLVM compiler: https://github.com/llvm/llvm-project/pull/70845

For more context, please visit my website: https://oestoleary.com. I'm excited to connect!

Here is the working link: https://ls.sondages.umontreal.ca/536189?lang=en

Implementing an RVM running on a GPU is definitely feasible, however, I'm not sure if it would be fast or efficient. For the case of Ribbit, you only need to write an RVM in a language that can compile to a GPU. An RVM is mostly a interpreter loop with some primitives. Maybe exposing the GPU primitives could enable heavily parallelizable scheme code ? It could be a fun experiment

> IIRC (might be wrong here) we had full support for JS, C, Python and Scheme from the start

I'm pretty sure we had support for JS, C, Python from the beginning as well. Then Scheme, posix shell, assembly came along for the ride.

> I'm unsure how support was kept throughout the versions but I know a much larger set of languages now support the runtime, at least for a subset of the features

One thing that really helped is CI testing! All the RVMs (the 16 targets) are now fully tested at each PR (https://github.com/udem-dlteam/ribbit/actions)

Hey ! One of the authors of Ribbit (https://github.com/leo-ard).

I'm really happy to see that the project is getting some attention! We made a lot of progress since the last post on HN (https://news.ycombinator.com/item?id=31096771). We are now fully R4RS compliant, support 16 different target languages with a sort of FFI with all of them.

We are currently working on flonum/bignum support and a guide for adding your own RVM (new host) so that you can run scheme in your favourite language. It should be coming soon!

I'll stay up to answer any questions about Ribbit!

Hi! One of the authors of Ribbit here (@leo-ard).

One of our goals was to reduce as much as possible a R4RS compliant REPL, because it is quite reasonably sized and doesn't support macros (we managed to fit it in 6.5KB!). We considered R7RS, but it was a bit too ambitious for a first goal. We plan on supporting R7RS eventually !

If you want to read more, section 4 of "A R4RS Compliant REPL in 7 KB" explains our rationale behind the choice of R4RS :

https://arxiv.org/pdf/2310.13589