bookowl / nemo Goto Github PK

The current API just sucks. Probably will be fixed with #1

The syntax for comments will be

# This is a comment

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.

Currently nemo uses threads and queues to implement piping. This isn't a very good solution for several reasons.

1. Threads are heavy, and spawning a new thread for each part of a pipeline can't be very efficient.
2. The order different parts of the pipeline are run in can't be controlled.

A single threaded solution would be much better. I've tried coroutines, but I can't get the code to work right without segmentation faults.

LLVM supports coroutines, so maybe someday nemo can become a compiled language.

The current module system you have works fine if you want to make functions with the standard library. But what about implementing new features, such as creating HTTP requests?

I am aware that this language is not fully developed and more of a project than an actual language, so this is not really an issue as much as it is an inquiry: how would you implement foreign modules into your language?

nemo needs

• Strings
• Vectors
• Hashmaps

If nemo is going to be useable for anything serious, it needs modules.

There will be two types of modules:

1. Rust modules. These will be written in Rust and dynamically loaded using libloading
2. nemo modules. These will be written in nemo.

The distinction will only be in the interpreter, not to nemo code.