I think the idea of creating such a workgroup is very welcome, especially since sooner or later people will start creating languages on top of Rust.
For example I am currently working (since last November) on a Scheme interpreter in Rust, with the purpose of replacing Bash in my “operational” scripts:
However before I started implementing it I made a survey of other Rust-based Scheme / Lisp implementations and found quite a lot of them (18 to be more precise):
Moreover due to the nature of Rust type system and ecosystem I think it makes a perfect candidate for implementing such languages.
However, there are quite some a few issues to overcome when using Rust to implement dynamically typed languages:
-
garbage collection is a huge issue; currently I rely on Rc<T> exclusively in my interpreter, which means cycles lead to memory leaks; therefore an important issue to tackle by such a workgroup is how to enable the implementation of garbage-collection system that is as easy to use as a simple Rc<T>;
-
dynamic dispatch; which pattern should one use to dispatch functions based on the “object” and “signature” of the arguments? for example a large portion of my code is dedicated to dispatching “primitive” procedures, and especially the ones that accept multiple number of arguments;
-
efficiently passing the barrier from dynamic typing of the intepreter language and the static typing required by Rust; for example all my primitive functions must accept the generic Value type, from which I must then “cast” the actual Rust type one expects (like an array, or string, etc.); currently I have a set of macros that try to match the arms of the enum Value, but I have a feeling this is quite inefficient…
-
efficient implementation of “expression” structures and how to “interpret” them – i.e. writing VM’s in Rust-compliant manner; many C-based Scheme implementations out there rely on using a stack / byte-code based VMs, which makes a lot of sense in C, however one can’t reuse that pattern in Rust without resorting to unsafe mem::transmute all over the place;
-
handling mutable types (used in the interpreted language) in the Rust-based code; and this was one of the toughest issues I had to tackle, because I now had to move around Ref<T> values; moreover when one is faced with two variants of the same type, say immutable and mutable strings, now one has to juggle an enum that holds either a reference to the internals of the immutable string, or Ref to the mutable one; (similar to cow but not quite;)
-
interacting with “opaque” data types when crossing the bridge from the interpreted language to Rust; for example for the “core” data types in my language I’ve used enum arms, but I also introduced an Box<Any> variant for the “other” less frequent datatypes;
-
“exception” handling; Rust uses Result<T, E> as an explicit return to handle errors; many programming languages like to “throw exceptions”; therefore one’s interpreter code is full of Result<T, E> and try! (call_some_function (...));
-
related to error handling there is the issue of “backtraces”; how should one implement an efficient and useful backtrace mechanism that would allow one to mix Rust-layers and interpreted layers; currently I have two mechanisms for backtraces: one based on the backtrace library to handle Rust backtraces, and a trivial “dumb” one to handle tracing in the interpreted code;
-
parsers, especially of the PEG-style; I currently use peg as the language parser, but it lacks the ability to parse “expression-by-expression” from a stream, which means I can’t use it to implement a function that “parses the next expression” from a file; and so far I have not found a parser (in Rust) that is easy to use and able to do this;
-
having the tests of the interpreted language “integrated” within cargo test framework; here thanks to the macro system and the include_str! I was able to “somehow” integrate them, but the result isn’t the nicest one…
-
green threads, continuations, and other “concurrency” constructs; (I haven’t even started thinking about these, but after a first look they seem far from trivial to implement…)
And these are only a few items that came in my mind while writing this. I’m sure there are other issues out there similar to these.
Now about the collaboration in such a workgroup, I think the best solution would be a mailing list (or equivalent).
I’ve seen mentioned IRC, and that would be a deal breaker for me (and perhaps many other).
Github issues (as is done for Rust RFC) might be a solution, but if one looks closer it actually mimics a mailing list. It might be best suited for discussing code, but for general discussions I think it’s a poor replacement for a good mailing list.
Therefore my vote (if it comes to it) is – in order of preference – a mailing list, GitHub issues, any other solution that allows notifications to be alerted via email.
I hope such a workgroup becomes reality, and make the life easier for language implementers out there.
