ZenScript, A new open-source language project.

I have decided to start a new open source (and open design) language project (working title "ZenScript") collaborating with shelby3 in GitHub, focusing on compile to JavaScript which will allow rapid prototyping and experimenting with features. The target is a strongly typed language targeted at generic programming as defined in "Elements of Programming" by Alexander Stepanov and Paul McJones, but in a garbage collected language, with some features like first class union types aimed at delivering concise code and eliminating boilerplate, and which enables a neat solution to Wadler's Expression Problem which I first heard from shelby3.

The idea is it will be a small single-paradigm language, a hybrid between functional / imperative.

The key features for the language:

  • Parametric polymorphism
  • Type classes
  • Union types
  • Type inference locally (within a module)
  • Python like compulsory indenting/layout
  • Sound type system

Additional features that would be good but not decided:

  • Type system is a logic language and can be used for metaprogramming
  • Unified type-class, record, and module syntax
  • Monadic effects
  • Higher ranked types (probably via first-class-polymorphism)
  • Higher kinded types
  • Type families

Here is a link to the discussions about the language: https://github.com/keean/zenscript/issues

All are welcome to come and comment and help shape the direction of the language. You don't have to contribute code, just helping with the design discussions would be appreciated (but please take note of the goals above).

There are the beginnings of a compiler, currently written in JavaScript (seemed appropriate), which is being developed using a test-driven-development methodology (mocha and chai for the unit test framework, and jshint to keep things clean). I am using the Parsimmon parser (inspired by Parsec). It will use a nano-pass architecture as correctness, and understandability more than performance are the first goals. Currently it can just about take a simple expression from the source language to AST and back to JavaScipt, but the language design is still in the early stages too.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

A link to a description of

A link to a description of high first-class union types solve the expression problem? Also see Ceylon which already has a number of these features.


I didn't see any mention of type-classes when I looked at Cylon. It also looks like Cylon provides classical object inheritance and subtyping, which are both things ZenScript aims to avoid to keep the language small and simple.

Ceylon models Java's

Ceylon models Java's subtyping via first-class union and intersection types. It's not at all a classical subtyping model.


Sorry I meant subclassing. Ceylon appears to have first class unions in common with zenscript, but not type-classes, which makes them quite different.

Expression Problem

Shelby3 explains the solution to the expression problem here: https://github.com/keean/zenscript/issues/2#issuecomment-248259132 I find a bit difficult to piece it together from the half-a-dozen posts linked though.


Well you should look at Felix since, apart from your layout requirement, it already does much you require, and quite a bit more. However it generates C++ not Javascript.

However I don't understand the "single paradigm" requirement, since you then specify a hybrid of functional and imperative programming.

Also, if you want to do anything remotely useful, forget implementing a compiler in Javascript. Pick Ocaml or Haskell or something else with a good type system, variants, products, first class functions, etc.

IMHO I'd give up on type inference. Its a bad idea in the first place, and in practical production languages overloading is more useful. Its hard to have both. In Felix, if you leave off the type of a parameter the function is implicitly generic. I never use that feature but its ok for three line scripts.

Type inference and overloading

Getting a little off topic, so maybe we should keep it brief, but why do you say that type inference is a bad idea in the first place?

It's not really that hard to have overloading & type inference. If not enough is known about the types to make overload resolution unambiguous, then the programmer needs to choose. In my project, the editor can help you with this.