Our great sponsors
-
https://github.com/mwerezak/sphinx-lang
An implementation of a dynamic programming language in Rust. Includes: Parser/Compiler, REPL, Virtual Machine, Bytecode Disassembler
This started out as a learning project to teach myself Rust. It has grown into a decently substantial piece of software and I've learned quite a bit in the process!
Some neat things:
+ A garbage collector that can store dynamically sized types without any double-indirection (i.e. I have my own Box implementation with manual alloc/dealloc)
+ The smart pointer used to reference GCed data is a thin pointer. The ptr metadata needed for DSTs is stored in the GC allocation itself, so that the GC smart pointer is just a single usize wide. This allows me to keep the core value enum Variant down to 16 bytes (8 bytes for data, the enum discriminant, and some padding).
+ The GC also supports weak references!
+ Statically dispatched type object model using a newtype wrapper and Rust's declarative macros. Ok, what that means is that I have a MetaObject trait that I can use to easily add new data types and define the behavior for specific types. Similar idea to Python's PyTypeObject though very different in implementation. However, I don't resort to dynamic dispatch or trait objects despite working with dynamically type data. Instead, I have a newtype wrapper over the core value enum Variant that statically dispatches to each of the enum branches! And then a few macros that minimize the boilerplate required if I want to add a new branch to Variant or a new method to MetaObject (just a single line in each case).
+ Different string representations! This was inspired by the flexstr crate. Strings that are short enough to fit inside a Variant are "inlined" directly in the value. Longer strings are either GCed or interned in a thread-local string table. All identifiers are interned.
+ An efficient implementation of closures inspired by Lua's upvalues.
The language is still pretty WIP. I'm planning to add an import system, a small standard library, and a few other things
(Yes, the name might not be the best, being also used by a well-known ReST docs generator, I'll take suggestions. I do like the name though, both as a reference to the mythological creature and the cat :D)
-
Tracking issue for native code is here: https://github.com/gleam-lang/gleam/issues/109 unlikely they will directly compile to WASM.
A similar language to gleam built on WASM is grain: https://github.com/grain-lang/grain
-
Mergify
Updating dependencies is time-consuming.. Solutions like Dependabot or Renovate update but don't merge dependencies. You need to do it manually while it could be fully automated! Add a Merge Queue to your workflow and stop caring about PR management & merging. Try Mergify for free.
-
One way to get at this: making your own language will show you not only what each thing means, but also what the underlying mechanics are!
Crafting Interpreters is a great guide on this: http://www.craftinginterpreters.com
-
Tracking issue for native code is here: https://github.com/gleam-lang/gleam/issues/109 unlikely they will directly compile to WASM.
A similar language to gleam built on WASM is grain: https://github.com/grain-lang/grain
-
Interesting project. Have you considered making an REPL using WASM in browsers as a playground?
I am developing this music live coding language and audio library:
I am now using Rhai.rs as the embedding language to write `meta' node in the audio graph. But for audio programming, the running time for each block should not exceed 3ms. In some cases, I found Rhai quite struggling with that. Perhaps dynamic languages have an inherit limitation on that? Wondering how do you see this issue and will performance be part of the future consideration of sphinx-lang?
-
Rust really has a great support for WASM. I made a tiny language as well, and managed to build targeting WASM in a few steps https://github.com/calcit-lang/wasi-calcit/blob/main/.github... .
Tips to notice is WASM runs inside a sandbox, which means threads, random numbers generator(not sure for WASI), FFIs, etc. have to be moved out of the core to prevent them being compiled to WASM, which would probably fail. For major part of the code, they can be compiled to WASM and WASI(WASM System Interface) very easily.
