• imperative (combined with strict, all this really means is that the language
  • strict (deterministic ordering of operations)
  • impure by default (with purity available)
  • caters to sequential statements and special control flow forms (like for, if, while as much as it does to expressions)
• strongly-typed
  • unsafe casts are possible, but conspicuous
• statically type-checked
  • types are inferred
  • polymorphic
• algebraic data types
  • supports pattern matching with match with robust coverage analysis
• some cost abstractions
  • garbage collection
  • deterministic destruction via ref-counting and/or defer or with behavior (TBD)

Zion prefers correctness and refactorability over performance. Zion targets scenarios where scalability is intended to happen horizontally, not vertically. That being said, Zion tries to be fast, using static compilation to native host architecture as its execution model. Zion is built on LLVM.

• In industry there are two primary archetypes of programming language users, Workers and Librarians. Experienced developers wear either of these hats, switching back and forth as necessary. This switching can happen as new dependencies and integrations are initiated and completed within the scope of feature or new product work.
  • Workers build trustworthy applications that solve problems. Workers demand a pleasant and ergonomic experience in order to remain focused on reaching their objectives.
  • Librarians extend the capabilities of the language by
    • Creating bindings to external libraries,
    • Integrating external libraries so as to appear fluid and seamless to the Workers,
    • Exposing extrinsic data via serialization that maintains type-safety and ergonomics to the Workers.

• Keep it simple, when possible.
• Keep it readable, when possible.
• Make algebraic data types compelling for state modeling.
• Reduce pain near process boundaries. Be opinionated on how to make serialization as comfortable as possible while retaining static type safety.

• Solving heavy compute problems is a non-goal. Solve those problems at a lower level, and use the FFI to access those components. Favor algorithmic scaling over bit twiddling and fretting over L1 cache hits.
• Pause-free execution remains a back-burner goal. (ie: Enabling Game loops, high-speed trading platforms, life support monitoring, embedded systems, etc...) However, in a future version, once language development settles down a bit, this will get more attention.
• In-language concurrency and asynchronicity will get treatment in the future. These can currently be solved at other levels of the stack (hint: use OS processes.) This is not because it's not important. But, basic ergonomics of the language come first.

Zion looks a bit like Python, minus the colons.

module hello_world

fn main()
	print("Hello, world!")

Comments use #.

fn favorite_number(x int) bool
	# This is a comment
	return x == 12

Zion is strict by default, not lazy. Memory is managed using garbage collection.

• discuss namespaces.
• discuss future plans for safe dynamic dispatch. (some thoughts exist here)
• discuss the std library layout.

Types are declared as follows:

# Declare a structure type (aka product type, aka "struct")
type Vector2D has {
	x float
	y float
}

# Note the use of the word "has" after the type name. This signifies that the
# Giraffe type "has" the succeeding "dimensions" of data associated with its
# instances.
type Giraffe has {
	name str
	age int
	number_of_spots int
}

type Gender is { Male Female }

type Lion has {
	name str
	age int
	gender Gender
}

type Mouse has {
	fur_color str
}

type NationalPark is {
	Zion
	Yellowstone
	Yosemite
}

type Bison has {
	favorite_national_park NationalPark
}

When a call to a function that takes a sum type is made, and there remain free type variables in the type of the parameters, they will be substituted with the bottom "⊥" type (void) during function instantiation.

./llvm-build.sh

Then add $HOME/opt/llvm/release_40/MinSizeRel/bin to your path. Be sure to add it before any existing versions of clang or llvm tools, etc...

• Ergo: Ability to import symbols from modules by name (symbol injection)
• Pattern-matching
  • ctor matching
  • int matching
  • tuple matching
  • string matching
• [-] Play: Rewrite expect.py in Zion
• Perf: Implement native structures as non-pointer values
• Perf: Escape analysis to avoid heap-allocation.
• Consider how to allow for-macro expansion to have a mutating iterator function. Does that mean pass-by-ref is allowed?
• Consider making all refs managed/heap-allocated (prior to a later escape-analysis test) in order to allow reference capture... maybe.
• Consider type-classes
• Implement fast range(i)
• Use DIBuilder to add line-level debugging information
• Implement an inline directive to mark functions for inline expansion during optimization
• Implement generic sort
• Data structures
  • string (as slices)
  • vectors
  • hash map
  • set
  • binary tree
  • avl tree / red-black tree
• decide on with (Python) / using(dispose) (C#) / 'defer' (Golang) style syntax for deterministic destruction - or ref-counting
• Rework debug logging to filter based on taglevels, rather than just one global level (to enable debugging particular parts more specifically)
• Ergo: Enable linking to variadic functions (like printf)
• Fix linking issues (rt_float.o, etc...) when running zion from non-zion root dir)
• Rename typeid function to ctor_id or something similar.
• Perf: Explore using a conservative collector
• Libs: Integrate JSON parsing and mess around with manipulating some existing JSON files
• Expose reflection library for dynamic structure analysis
• Func: Enable let vars at global scope
• Automatically configure default POSIX/C/System "int" size on first boot of compiler
• Add safety checks on casting (as)
• Exercise: implement parser combinators in Zion
• Implement closures with capture by value
• Implement backtracking in unification of product types
• Consider marking null-terminated strings differently for FFI purposes (ended up doing this as part of "safe-unboxing" for easier FFI.
• Implement slice array indexing rg[s:end], etc...
• Implement vector slicing for strings and arrays
• Optimize scope_t's get_nominal_env and get_total_env to be cached
• Maintenance: Change all status_t parts of compiler to use exceptions
• Check for duplicate bound function instantiations deeper within function instantiation
• Change := to be let by default
• (un)signed integers
  • write a C integer promotion compatibility test as part of test framework
  • integers as a type with parameterized number of bits and whether to use sign-extend or zero-extend
  • promotions upon binary operators
  • prevent overloading integer operations unless one side is not an integer
  • deal with casting integers
• implement let declarations
• change str to use wchar_t as its underlying physical character type
  • use C99's mbstowcs and wcstombs to convert back and forth
  • propagate usage of utf8 for char
• 'for' syntax - based on tests/test_list_iter.zion pattern
• Ternary operator
• Logical and/or (build with ternary operator)
• Type refinements for ternary / conditional expressions
• Implement vector literal checking and code gen
• Design/Implement tags functionality (for integration with ctags and LSP)