[Zeolite Programming Language][zeolite]

[![Haskell CI Status][action-status]][action-zeolite] [![Hackage Status][hackage-status]][hackage-zeolite-lang]

Zeolite is a statically-typed, general-purpose programming language. The type system revolves around defining objects and their usage patterns.

Zeolite prioritizes making it easy to write maintainable and understandable code. This is done by rethinking standard language idioms and limiting flexibility in some places while increasing it in others. In particular, emphasis is placed on the user's experience when troubleshooting code that is incorrect.

The design of the type system and the language itself is influenced by positive and negative experiences with Java, C++, Haskell, Python, Ruby, and Go, with collaborative development, and with various systems of code-quality enforcement.

Due to the way GitHub renders embedded HTML, the colors might not show up in the syntax-highlighted code in this document. If you use the Chrome browser, you can view the intended formatting using the Markdown Viewer extension to view the raw version of this document.

Table of Contents

• Project Status
• Language Overview
  • Programming Paradigms
  • Parameter Variance
  • Parameters as Variables
  • Integrated Test Runner
  • Integrated Build System
  • Data Encapsulation
• Quick Start
  • Installation
  • Hello World
• Writing Programs
  • Basic Ideas
  • Declaring Functions
  • Defining Functions
    • Using Variables
    • Calling Functions
    • Functions As Operators
    • Data Members and Value Creation
    • Conditionals
    • Scoping and Cleanup
    • Loops
    • Multiple Returns
    • Optional and Weak Values
    • Deferred Variable Initialization
    • Immediate Program Termination
    • Call Delegation
  • Function Argument Labels
  • Function Return Labels
  • Using Parameters
  • Using Interfaces
  • Immutable Types
  • The #self Parameter
  • Type Inference
  • Other Features
    • Meta Types
    • Explicit Type Conversion
    • Runtime Type Reduction
    • Value Instance Comparison
    • Limited Function Visibility
  • Builtins
    • Reserved Words
    • Builtin Types
    • Builtin Constants
    • Builtin Functions
    • Procedural Operators
• Layout and Dependencies
  • Using Public Source Files
  • Standard Library
  • Modules
• Unit Testing
  • Writing Tests
  • Code Coverage
• Compiler Pragmas and Macros
  • Source File Pragmas
  • Procedure Pragmas
  • define Pragmas
  • unittest Pragmas
  • Local Variable Rules
  • Expression Macros
• Known Language Limitations
  • Reference Counting

Project Status

Zeolite is still evolving in all areas (syntax, build system, etc.), and it still lacks a lot of standard library functionality. That said, it was designed with practical applications in mind. It does not prioritize having impressive toy examples (e.g., merge-sort or "Hello World" in one line); the real value is seen in programs with higher relational complexity.

Language Overview

This section discusses some of the features that make Zeolite unique. It does not go into detail about all of the language's features; see Writing Programs and the [full examples][examples] for more specific language information.

Programming Paradigms

Zeolite currently uses both [procedural][procedural] and [object-oriented][oop] programming paradigms. It shares many features with Java, but it also has additional features and restrictions meant to simplify code maintenance.

Parameter Variance

The initial motivation for Zeolite was a type system that allows implicit conversions between different parameterizations of parameterized types. A parameterized type is a type with type "place-holders", e.g., templates in C++ and generics in Java.

Java and C++ do not allow you to safely convert between different parameterizations. For example, you cannot safely convert a List<String> into a List<Object> in Java. This is primarily because List uses its type parameter for both input and output.

Zeolite, on the other hand, uses [declaration-site variance][variance] for each parameter. (C# also does this to a lesser extent.) This allows the language to support very powerful recursive type conversions for parameterized types. Zeolite also allows [use-site variance][variance] declarations, like Java uses.

Building variance into the core of the type system also allows Zeolite to have a special meta-type that interfaces can use to require that implementations return a value of their own type rather than the type of the interface. This is particularly useful for defining interfaces for iterators and builders, whose methods often perform an update and return a value of the same type.

Parameters as Variables

Zeolite treats type parameters both as type place-holders (like in C++ and Java) and as type variables that you can call functions on. This further allows Zeolite to have interfaces that declare functions that operate on types in addition to interfaces that declare functions that operate on values. (This would be like having abstract static methods in Java.)

This helps solve a few separate problems:

• Operations like equals comparisons in Java are always dispatched to the left object, which could lead to inconsistent results if the objects are swapped: foo.equals(bar) is not the same as bar.equals(foo). This dispatching asymmetry can be eliminated by making equals a type function (e.g., MyType.equals(foo, bar)), and further creating an interface that requires implementations to support such calls.

• Factory patterns can be abstracted out into interfaces. For example, you could create a factory interface that requires an implementation to parse a new object from a String, without needing to instantiate the factory object itself. You could just implement the factory function directly in MyType, without needing a separate MyTypeFactory.

Integrated Test Runner

The major advantage of statically-typed programming languages is their compile-time detection of code that should not be allowed. On the other hand, there is a major testability gap when it comes to ensuring that your statically-typed code disallows what you expect it to.

Zeolite has a special source-file extension for unit tests, and a built-in compiler mode to run them.

• Tests can check for runtime success, compilation success, compilation failure, and even crashes. Normally you would need a third-party test runner to check for required compilation failures and crashes.

• The test mode includes a command-line option to collect code-coverage data, which can be critical for determining test efficacy.

Nearly all of the integration testing of the Zeolite language itself is done using this feature, but it is also supported for general use with Zeolite projects.

Integrated Build System

The Zeolite compiler supports a module system that can incrementally compile projects without the user needing to create build scripts or Makefiles.

• Modules are configured via a simple config file.
• File-level and symbol-level imports and includes are not necessary, allowing module authors to freely rearrange file structure.
• Type dependencies are automatically resolved during linking so that output binaries contain only the code that is relevant.
• Module authors can back Zeolite code with C++.
• The module system is integrated with the compiler's built-in testing mode.

This means that the programmer can focus on code rather than on build rules, and module authors can avoid writing verbose build instructions for the users of their modules.

Data Encapsulation

The overall design of Zeolite revolves around data encapsulation:

• No default construction or copying. This means that objects can only be created by explicit factory functions. (A very common mistake in C++ code is forgetting to disallow or override default construction or copying.) This also means that accidental deep copying is not even possible in Zeolite.

• Only abstract interfaces can be inherited. Types that define procedures or contain data members cannot be further extended. This encourages the programmer to think more about usage patterns and less about data representation when designing interactions between types.

• **No "privil