FAQ

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 (Paul) worked 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); Our goals for Plasma are different from the goals of Mercury. With Plasma we 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?

We believe that purely-declarative strongly statically typed languages are the only sensible option for creating reliable software. However the available options (including 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. We also have some exciting plans for parallel and concurrent programming.

We're writing Plasma because we believe that there is a need for 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 we 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.

Why do the tools begin with plz?

They didn't always. Some of the tools begun with "pz" for Plasma Zero, it was an idea I had about compiler construction that probably wont help and I've abandoned. People saw the pzasm and pzrun and figured it was close to plzrun (please run); and well, we couldn't help ourselves. All the tools now begin with plz and the main tool, once it exists, will be simply plz and will accept arguments like build.

What paradigm is it?

We call it a "side-effect free language", however this is just another way of saying "purely functional" but without emphasising functional. We do this to avoid giving readers the wrong impression, since we do not want to emphasise category theory.

Like pure functional languages Plasma code cannot have side effects. Unlike functional languages we declare affects in terms of resources, and Plasma's syntax looks 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 we are not using uniqueness typing to manage effects. Peter Schachte created a concept called Resources for his language Wybe. We intend to extend this concept a little further and use it to manage effects.

Monads are useful and may be supported, but will not be used for effects or to the extent that they are in Haskell.

Is this a research language?

No. Well, mostly-no.

We want to make a language that is accessible and tends to have few sharp corners. That means our priorities will be different from most researchers, we don't expect Plasma to be a suitable "fit" for most research, and want to avoid most research since it can create ongoing maintenance and ease of use problems.

There is one exception: auto-parallelisation. Part of the reason for creating Plasma is to continue the auto-parallelisation research that Paul started with the Mercury language.

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, they'll probably be useful for loops.

Dependent types?

No. While dependent types and other fancy type systems ideas are promising, we do not think that they are ready for mainstream. And our policy of avoiding research means that we're not going to be an early adopter for these ideas.

Ownership system (like Rust)?

No. We believe that most of the time most developers, writing most software do not need an ownership system to make their code sufficiently fast or use fit within available memory, a GC is usually good enough. Ownership makes the language and its use more complex, and the benefits are not worth the cost of this complexity.

It is possible for a compiler to analyse lifetimes of values automatically, no annotations are needed. It wont infer everything but what it can't can be handled by a GC. This gives many of the benefits of ownership but functions like an optimisation. This is where the research for ownership started, with an optimisation called region based memory management.

Other planned features are described in the roadmap.

What is the intended purpose? Web programming / scripting / systems?

I (Paul) 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! We 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. We also hope that Plasma will be good at numerical problems: simulations and scientific computing.

Without update-in-place it can be tricky to model things like graphs. However are solutions to this that the functional programming world has developed, they'll just look a bit different if you haven't seen them before.

Can Plasma be used in a given environment? (OS support? scalability?)

We develop and test on Linux on x86_64, using Mercury and GCC/Clang. 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.

Will it have a JavaScript/Ruby/X backend?

We want only a small number of backends to maintain. That said we think the following backends would be valuable and hope to support them: bytecode, native code (or LLVM) and WebAssembly.

Our bytecode intermediate format also allows other developers to write bytecode interpreters (or translators) for their favorite environments.