BookOwl / nemo

A fishy programming language.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Nemo should focus on coroutines, not pipes.

BookOwl opened this issue · comments

I originally created nemo to see what a language that provided high level support for piping would be like. I believe that is has succeed in this aim and taught me several things.

Pipes are good, but coroutines are better.

Coroutines are much more general than pipes and allow several different styles of organizing code. Pipes are very specific, and can be easily created with coroutines.

I believe nemo would be a much better and more useful language if it makes working with async code using coroutines as easy as sync code, while still being fast.

Similar things should be similar, and different things should be different

Despite nemo not being a functional (as in the paradigm), I have tried to make much of its syntax functional. This made things unnecessarily confusing. I'm going to try to make the syntax more traditional in places where the language is like other languages, but still keep the new stuff different.

The source should be simple, yet fast.

pub fn eval<'a, 'b>(ast: &'a Expr, env: ProtectedEnv, this: Arc<Mutex<queue::Consumer<Value>>>, next: Arc<Mutex<queue::Producer<Value>>>) -> Result<Value, Error<'b>> {}

nemo's current source code is complex and not very fast compared to things like bytecode VMs and JITs. #7 can be fixed as part of this.

The solution

I believe that the best way to fix this is to redesign nemo with an eye towards coroutines and async code, and completely rewrite the source.