- What is it written in?
Mercury, until it can be bootstrapped, then hopefully Plasma
- What license is it distributed under?
Different parts of Plasma are distributed under different licenses. The code is almost all the MIT licese with some small parts LGPL. See the LICENSE file for more information.
- You work on Mercury already, so is this Mercury 2.0?
No. While it's fair to say that Plasma is related to Mercury (they're both declaratively pure strongly typed eager languages); My goals for Plasma are different from the goals of Mercury. With Plasma I aim to create a compromise between declarative languages (Like Mercury and Haskell) and imperative languages like C, Java and Go. Plasma's syntax looks more like an imperative language, while it's type system and pure semantics are more like a declarative language. Plasma is not a logic programming language.
- Why are you writing it?
I believe that purely-declarative strongly statically typed languages are the only sensible option for creating reliable software. However the two main options Haskell and Mercury have several problems, including being difficult to learn. Additionally imperative programming provides some specific advantages over declarative programming, for example the convenience of expressing loops directly in the language's syntax and manipulating data in arrays. I also have some exciting plans for parallel and concurrent programming.
I'm writing Plasma because I believe that we need an easy-to-learn-and-use purely-declarative language that doesn't make arrays and loops awkward to use.
- Why the name Plasma?
Plasma refers to the fourth state of matter. The name Plasma comes from a very far-away goal I have for parallel computing. This is so far away that it's not practical to talk about it right now.
Plasma is also good for creating several puns, eg: Plasma is so hot right now.
- What paradigm is it?
Technically it will be a purely functional language, this means that code cannot have side effects. However it will look more like a procedural language which should make it more familiar to more people. It will be strongly statically typed (a type system similar to Haskell, Mercury or OCaml's) and use eager evaluation (like OCaml or Mercury).
- If it is pure, how do you handle effects? Are there monads?
Monads are not used to handle effects as they are in Haskell, and unlike Mercury and Clean I do not plan to use uniqueness typing to manage effects. My colleague Peter Schachte created a concept called Resources for his language Wybe. I intend to extend this concept a little further and use it to manage effects.
Monads are useful and may be supported, but wont be used for effects or to the extent that they are in Haskell.
- Does/will it have/support X?
- Threads, channels, mvars, futures and similar?
- Yes, not implemented yet.
- Green threads?
- The threading model will be N:M, meaning that greenthreads will be used and multiplexed onto native threads.
- Type classes or parametric modules?
- We're working interfaces which combine benefits of both type classes and parametric modules.
- Higher kinded types?
- Probably, I think they'll be useful for loops.
Other planned features are described in the roadmap.
- What is the intended purpose? Web programming / scripting / systems?
I really don't like these separations. A good language with a good implementation should be suitable in many environments. A more practical question is can a given domain be modeled easily in Plasma? Another relevant question is can Plasma be used in a given environment?
- Can a given domain be modeled easily in Plasma?
Good question! I hope that Plasma will be very good at problems of a symbolic nature: most non-numeric problems, the kind of problems that benefit from a type system like Haskell's. I also hope that Plasma will be good at numerical problems: simulations and scientific computing.
- Can Plasma be used in a given environment? (OS support? scalability?)
I develop on Debian Linux on x86_64, using Mercury and GCC. Occasionally I test using Clang and/or x86. Development is at a rather early stage, performance is not relevant at this stage, but we are keeping performance and scalability (up and down) in mind.
I would prefer to have only a small number of backends to maintain. Therefore I will concentrate on the two backends that I have planned: bytecode and native code (or LLVM). However, a bytecode intermediate format allows other developers to write bytecode interpreters (or translators) for their favorite environments. eg: the JVM.