Cobre is an abstract machine specification, simple enough to make easy writing a complete implementation from scratch, and versatile enough to represent a wide range of languages and paradigms.
Ideally, Cobre would be a platform in which a developer can write in any language and can interact easily with modules written in any other, which can run in a lot of different platforms, like different OS's, the web, the JVM or embedded in games and applications.
It's intended that many features available in many programming languages or elsewhere, like OOP, dynamic dispatch, object serializing, etc. be implemented in standard libraries and conventions, instead of on Cobre itself.
This project holds the design and an implementation written in Nim. The main documentation is in [docs/Module Format.md](docs/Module Format.md).
Note: The main documentation is in english, but files in notes and a few source comments here and there are in spanish. I'm working on translating the important stuff to english.
License: This project is open source software, distributed under the MIT license.
I want to develop in any platform, in any language I want, with the libraries I like.
I also want all of my programs to be as fast as Cee. One can only dream, right?
How to use
To install cobre, you need the Nim language. Run
make install as the superuser, then you can run any cobre module with
cobre <module_name>, the module has to be in the working directory or installed in the system. To install a cobre module run
cobre --install <file>, the file has to have the module name.
To execute a Cobre module, use
- JVM: The most popular and the main example of a virtual machine. It has a big ecosystem of libraries, frameworks and amazing languages like Scala and Clojure. The problem is that it's very big and complex and making a compilant implementation is very very difficult, and another is that it's built specifically around the Java language and any Language implementation must adapt to the Java way to interoperate with the ecosystem.
- CLI/.Net: Microsoft's Java, and as such just as inadequate. The first difference is that the main imlementation (and because of the complexity almost the only one) is Windows specific, which strongly conflicts with Cobre's multiplatforms objective. The other difference is that it's designed to be more language neutral, and that's good but it's not enough to compensate the downsides.
- Parrot: Mainly designed to support many dynamic languages, and although simpler than the JVM and the CLI, it's still too complex to understand all a once.
- LLVM: It's actually a compiler intermediate representation, not by itself a compilation target. LLVM IR files are not really distributable, so one has to distribute either the source code and expect everyone to have the language's compiler installed, or the machine code and expect everyone to have the same architecture and OS, or distribute many diferent binaries for each system flavour (potentially a lot).
- MuVM, WebAssembly: The designers of these projects share a lot of Cobre's objectives, but their approach abstracts very lightly a physical machine, so compiling to them is similar to compiling to x86. I believe a simpler, higher level design is better to mantain the health of the project and it's ecosystem, compiling for physical machines is hard, that's why scripting languages are far more popular.
- Lua, Scheme: These are not as similar to the other projects, but they are included as examples of how a very simple and straightforward design welcomes involvement and progress. Scheme for example has a lot of fully compilant implementations, and Lua has one of the (if not the) fastest scripting languages implementations, written by a single person.
TLDR: Most of the existing projects are too big and complex for one single person to understand, and those that aren't (like Lua and WebAssembly), are not versatile enough.
Things that need to be done
- Closures, they are ubiquitous and too hard for language implementors
- Module level code and parametric modules are ugly: modules are duck typed maps and type/function to value and vice versa is ugly
- Finish the standard library. It must have:
- Variants / Unions (possibly with Any)
- Any type
- Dynamic language tables
- Shell type (Alias)
- OOP Class type
- Ownership Model? (Simplified?)
- Module manipulation
- Figure out concurrency and memory safety
- Scheme on cobre
- Make the cobre module dumper in a cobre language
- Make a static analysis tool
Some things I wish existed, created with or on top of Cobre
- A better app centric web.
- A Unity or Godot level game engine scripted with Cobre.
- Cobre cross language libraries on top of various protocols, like DBus, Ajax, REST Apis.