Coalton [1] is a Lisp language that has Hindley-Milner type inference with type classes. Its syntax actually resembles the prototype syntax from TFA pretty closely. The Coalton syntax-equivalent would be:<p><pre><code> (define-type (Option :a)
(Some :a)
None)
(let ((x (Some 5)))
(match x
((Some y) y)
((None) (random))))
(declare random (Distribution :a => Unit -> :a))
(define (random)
(sample (thread-rng)))
(define-class (Eq :t)
(= (:t -> :t -> Boolean)))
(define-instance (Eq Number)
(define (= lhs rhs)
(num-equal lhs rhs)))
</code></pre>
Of course types and classes like Option and Eq are built-in already.<p>Coalton is based on Common Lisp (and allows free mixing with CL code) instead of Scheme however, though Coalton is a Lisp-1 and would feel relatively at-home to any Scheme programmer.<p>[1] <a href="https://github.com/coalton-lang/coalton">https://github.com/coalton-lang/coalton</a>
Also a shout out to Steel (<a href="https://github.com/mattwparas/steel">https://github.com/mattwparas/steel</a>), another Scheme-on-Rust which is more active.<p>The Rust community has given us at least two Scheme runtimes, several JS runtimes, but no Clojure interpreter yet that I'm aware of. There are a few zombie projects squatting on the name (seems common in Rust) but no viable releases.
The Helix editor, a popular alternative to Vim, is going to implementing it's plugin system in a Scheme-like language. Helix is also written in Rust.<p><a href="https://github.com/helix-editor/helix/discussions/3806#discussioncomment-6686976">https://github.com/helix-editor/helix/discussions/3806#discu...</a>
Nice work! It's a good write-up, too.<p>Hygienic macro expansion is one of the things I still haven't implemented before. I remember a [talk][1] where Matthew Flatt illustrates the idea of sets of scopes, and choosing the largest intersection. I see in your implementation there are sets of "marks" in syntax objects, is that what's going on there?<p>I haven't played with rust, but when I do I'll be able to play with this scheme too.<p>[1]: <a href="https://www.youtube.com/watch?v=Or_yKiI3Ha4" rel="nofollow">https://www.youtube.com/watch?v=Or_yKiI3Ha4</a>
I think you make a pretty bad case for how embedding a Scheme interpreter is going to help with the pain points of async. Listing "stack traces full of tokio code" and then seemingly proposing to solve that by adding more glue to pollute the stack traces is especially weird.
What would be really nice is a new lisp which actually allows for incredibly interactive programming similar to common lisp, but which targets a runtime like the v8 engine maybe.
Because I think a lot of people are missing out on the Smalltalk / Common Lisp experience.<p>Even Clojure and other lisps do not enable that level of interactive programming which the break loop in Common Lisp does.
I'm more of a R7RS kinda guy but I appreciate this, especially the types. Scheme allows for extremely non-linear memory access which means you necessarily need dynamic memory management and garbage collection. IMO once you're to that spot, there's little reason to stick with Rust, though it being the implementation language is interesting in itself. That being said, there are battle tested Scheme implementations out there that have fantastic FFI APIs that would probably work just as well if you don't mind a small bit of C to glue things together.
This seems like a great idea and I support the effort. It was not clear to me on first read though that what was being proposed is not an extension to current async rust (compiling code to a series of state machines), but a completely alternative design utilizing a context switching runtime like Erlang or Go. If I interpreted that wrong please correct me.<p>Part of me wonders, considering that rust is a systems programming language, how difficult would it be to write a runtime like that in rust so that there is no need to use a second language?
I wonder if people are in a way misusing Rust by trying to use it to build everything. It's designed to be a systems language, one for writing OSes, drivers, core system services, low level parsers, network protocols, compilers, runtimes, etc.<p>There's no way a low-level systems language like this is going to be quite as ergonomic as a higher level more abstract garbage collected language.
To the author, if you're reading this:<p>> But while I thing that async Rust is well designed<p>At least one typo, thank you for not using an LLM to spit out an article. :)
Why do people put up with the Lisp syntax? I get that it's super simple for computers to parse, but it's definitely not pleasant for <i>humans</i> to parse, and humans are the ones reading/writing code.<p>I would have thought some very simple syntactic sugar would make it a lot nicer to work with. Has anyone done that?
> I believe that it is a remarkably well designed language<p>> and just overall a poor debugging experience make async Rust a frustrating experience for rapid iteration.<p>> is the result of conscious trade-offs, trade-offs that I believe were chosen correctly. I don’t believe that async Rust necessarily needs to change at all, although I don’t doubt that the experience could be improved.<p>That's rust for you. It's a remarkably well designed language. Except for all the ways it isn't. What's hilarious to me is none of these are even deep or hard to find issues. Right out of the gate.. cargo is a wart.. and async was designed inside out.<p>Remarkable. Indeed.<p>So, _of course_, let's use it to implement a _different_ language entirely. The niche is disappearing.