3 ms·

> `List(Vec<RispExp>)` The big question when implementing a runtime for a Lisp-like language in Rust is how the interpreter will interact with the GC. It looks

> `List(Vec<RispExp>)` The big question when implementing a runtime for a Lisp-like language in Rust is how the interpreter will interact with the GC. It looks like this project has avoided most of the complexity by not implementing actual lists, and allowing multiple references to the same value to exist only in restricted circumstances, hewing close to Rust's ownership model rather than a typical Lisp's. I wonder, is the plan to stay on this side of the space, as a lightweight language with potentially smooth FFI interoperation with other low-level/Rust code? Or to rewrite almost everything to support the high-level semantics of list-processing languages, with their emphasis on shared structure?

stopachka 7y ago
Great question firethief! I think both approaches -- a) sticking close to rust and supporting beautiful interop, or b) creating our own GC and using interesting data structures (I've wanted to implement persistent vector tries for a while) -- could be very cool. For now, this was more of a toy project. If you have an interest in pushing either of these directions, would love to talk!
- Sandra435345 7y ago
  Superb Online job opprtunity.Earn Upto $11000 to $15000 per month.Easy Work From Home Job to Making more Dollars Than you Expect. Its True. Just Visit This Site ------------> https://goo.gl/7CLERv https://goo.gl/7CLERv
yellowapple 7y ago
> I wonder, is the plan to stay on this side of the space, as a lightweight language with potentially smooth FFI interoperation with other low-level/Rust code? I personally hope this is the case; I feel like Lisps in that space are scarce. Strange interactions between the GC and "alien" functions are one of the things that make FFI painful even when using a Lisp with otherwise-thorough FFI support (like Chicken Scheme or most Common Lisps).
- firethief 7y ago
  I think ultralight scripting languages are an interesting quadrant of language space, but I'm not sure the strengths of Lisp would be evident in a language without lists.
  - yellowapple 7y ago
    Fair point. Perhaps "Lisp" would be a misnomer, but I do think there's value in an S-expression-based scripting/configuration language even if that language doesn't insist on revolving entirely around linked lists and the semantics/quirks thereof. Seems like vectors/tuples/structs should be just as valid as lists for a program to represent itself.
etaoins 7y ago
The way I’ve approached it in my compiler [1] is that garbage collection can never occur while Lisp/RFI (Rust function interface) code is executing. Once the program returns to the event loop GC can occur with a small number of known roots. This works because there will be no way to block without waiting on a future which can then return to the event loop. I’m considering adding a `conditional-gc` macro for long running computations that’s internally implemented as waiting on a future that’s immediately resolved. This means that RFI code can treat GCed values as having a `'static` lifetime. One caveat is that RFI code cannot capture values except for a few special runtime functions. This works naturally with the language’s pure functional design, however. As far as data structures go its impossible to support performant Lisp code by implementing lists as native vectors; the guarantees and idioms are too different. My runtime [2] provides Rust bindings for data types that e.g. allow you to create an `Iterator` from a list or construct a list from one. That should allow transparent interoperability with idiomatic Rust patterns and data structures. [1] https://arret-lang.org/ https://arret-lang.org/ [2] https://rustdoc.arret-lang.org/arret_runtime/index.html https://rustdoc.arret-lang.org/arret_runtime/index.html

stopachka 7y ago

Great question firethief! I think both approaches -- a) sticking close to rust and supporting beautiful interop, or b) creating our own GC and using interesting data structures (I've wanted to implement persistent vector tries for a while) -- could be very cool. For now, this was more of a toy project. If you have an interest in pushing either of these directions, would love to talk!

Sandra435345 7y ago
Superb Online job opprtunity.Earn Upto $11000 to $15000 per month.Easy Work From Home Job to Making more Dollars Than you Expect. Its True. Just Visit This Site ------------> https://goo.gl/7CLERv https://goo.gl/7CLERv

yellowapple 7y ago

> I wonder, is the plan to stay on this side of the space, as a lightweight language with potentially smooth FFI interoperation with other low-level/Rust code? I personally hope this is the case; I feel like Lisps in that space are scarce. Strange interactions between the GC and "alien" functions are one of the things that make FFI painful even when using a Lisp with otherwise-thorough FFI support (like Chicken Scheme or most Common Lisps).

firethief 7y ago
I think ultralight scripting languages are an interesting quadrant of language space, but I'm not sure the strengths of Lisp would be evident in a language without lists.
- yellowapple 7y ago
  Fair point. Perhaps "Lisp" would be a misnomer, but I do think there's value in an S-expression-based scripting/configuration language even if that language doesn't insist on revolving entirely around linked lists and the semantics/quirks thereof. Seems like vectors/tuples/structs should be just as valid as lists for a program to represent itself.

etaoins 7y ago

The way I’ve approached it in my compiler [1] is that garbage collection can never occur while Lisp/RFI (Rust function interface) code is executing. Once the program returns to the event loop GC can occur with a small number of known roots. This works because there will be no way to block without waiting on a future which can then return to the event loop. I’m considering adding a `conditional-gc` macro for long running computations that’s internally implemented as waiting on a future that’s immediately resolved. This means that RFI code can treat GCed values as having a `'static` lifetime. One caveat is that RFI code cannot capture values except for a few special runtime functions. This works naturally with the language’s pure functional design, however. As far as data structures go its impossible to support performant Lisp code by implementing lists as native vectors; the guarantees and idioms are too different. My runtime [2] provides Rust bindings for data types that e.g. allow you to create an `Iterator` from a list or construct a list from one. That should allow transparent interoperability with idiomatic Rust patterns and data structures. [1] https://arret-lang.org/ https://arret-lang.org/ [2] https://rustdoc.arret-lang.org/arret_runtime/index.html https://rustdoc.arret-lang.org/arret_runtime/index.html