Eric Holk, a programming languages researcher, writes about Rust, GPU compilers, the Harlan language, and Scheme.
HN commenters cite it as an early source on compiling Rust for GPUs, booting to Rust, and understanding continuations through a Scheme interpreter.
You may find this paper helpful [1]. As noted there, syntax-rules consists really of two different parts: (1) the hygiene-preserving macro expander and (2) the pattern-matching facility. Once you wrap your head around the two pieces, it's actually pretty straightforward to implement them both. It's very common to write some "low-level" macro facility as a stepping-stone to syntax-rules (such as explicit-renaming macros or syntactic closures): the implementation of syntax-rules then becomes a composition of the pattern-matcher and the low-level facility. A tutorial implementation of an appropriate pattern-matcher can be found at [2],[3].
There's lots of good reading to be found at the ReadScheme Library [4]. Most if not all of the references in [1] can be found there.
Tangentially: yeah, syntax-rules kinda flies in the face of the oft-mentioned minimalism of Scheme, but there's a reason for it: at the time syntax-rules was standardized, there was no consensus on which (if any) low-level facility should be standardized (and, really, there still isn't any such consensus). The reason syntax-rules operates as a pattern-template rewriting system rather than as a procedural system is that such a system is able to guarantee that the macros it produces are hygienic in a (comparably) simple and intuitive way. The idea was to standardize on a high-level system so that Scheme could have a standard macro facility, whilst leaving the low-level systems open for further…
I really should update the user guide, since the language has changed a lot in the last year.
I have an earlier post that discusses a couple of the optimizations that Harlan does: http://blog.theincredibleholk.org/blog/2013/06/10/some-simple-gpu-optimizations/
To me the win for Harlan over CUDA is its region system, which lets you work with more intricate pointer structures in the GPU. For example, there is an interpreter for the Lambda Calculus as one of the test cases, which would be much harder to do in straight CUDA: https://github.com/eholk/harlan/blob/master/test/lambda3.kfc
Very soon, Harlan will have support for higher order procedures, which is also not available in CUDA.
> Despite my strong attachment to the Rust community and Rust’s perfect suitability for kernels1, I’ll be writing the kernel in C. Mostly because it is unlikely people inside the university will be familiar with Rust, but also because GNU-EFI is a C library and I cannot be bothered to bind it. I’d surely be writing it in Rust were I more serious about the project.
I saw an example of booting from UEFI in Rust: http://blog.theincredibleholk.org/blog/2013/11/18/booting-to-rust/
Rust is a low-level language so everything user-space can be implemented, and the main (and only) compiler rustc uses an industrial strength optimiser (LLVM) which has support for automatic vectorisation.
Furthermore, the type system is designed to be very good for high-performance concurrency.
See http://blog.theincredibleholk.org/blog/2012/12/05/compiling-rust-for-gpus/ for an example of using Rust on a GPU, and I can only imagine that it has become easier since then.
Is eholk no longer active in Rust-land? I remember reading his post [1] about compiling Rust for GPUs (i.e. app code + OpenCL kernels from a single source) back in 2012 and getting quite excited. Presumably generating SPIR-V wouldn't be vastly different in principle.
[1] http://blog.theincredibleholk.org/blog/2012/12/05/compiling-rust-for-gpus/
Language development have not been "stalled", it's just mainly under the radar.
Some nice designs are out there, see Vobla and Pencil [1] for example, or Harlan [2] as another extreme.
[1] http://carp.doc.ic.ac.uk/external/dissemination.php
[2] http://blog.theincredibleholk.org/blog/2013/06/28/announcing-the-release-of-harlan/