Some more Orchid progress. Dynamic dispatch, pattern matching and template strings:

Not some fake Rust-like template strings either, this is a recursive grammar

I don't have a good dynamic dispatch example because moving things out of Rust and into Orchid for the sake of demonstration is both silly (rust is way faster) and laborious, but here's a really shoddy example

The cool bit is that none of these are core language features.

Dynamic dispatch uses a parser plugin to recognize type and trait declarations and the Rust FFI to interact with the data the plugin builds,

Pattern matching is a completely native Orchid macro

Template strings are a lexer plugin which translates the templated parts to string concatenation, and the plugin API allows for recursion, so the lexer plugin doesn't even need to statically link its own recursive lexer callback

I'm slowly convincing myself to write a language server, because writing dynamically typed macro-heavy code with autocurry without dev tooling feels like walking barefoot through a party district.

@lorentz what are template strings? Strings with interpolation?

@Lensflare That's the word I was looking for!

Cool stuff! How fast is it in comparison to python?

I miss working on my interpreter :( It's so much fun to work on. I lost my stuff and too lazy to write a lexer / tokenizer for 10th time. Writing interpreters is not for lazy people.

Did you already work on fileIO/sockets?

@retoor rudimentary file IO is done, sockets still aren't. Right now it's very slow because on every step the interpreter acquires and releases a mutex, figuring out a better synchronization mechanism is my priority right now.

@lorentz why a mutex? It's not multithreaded right?

@retoor I want to have parallel workers very soon for an integrated test runner. I could instantiate the environment for each worker thread, but I suspect that I'll bump into use cases that require threading as soon as I start actually building things that can be scripted with Orchid.

By default in Rust you can't really hold on to lock guards, because they reference the lock so whatever way you access the lock has to stay pushed on the real stack as long as the guard is alive, and Orchid (as of yesterday) uses a virtual stack to turn stack overflow into a managed error.

I remembered that about a year ago I made a crate to solve exactly this problem: https://github.com/lbfalvy/bound

I don't know whether it tells more about Rust or me that the second thing I ever made used unsafe code to reach past the language's constraints