Language Characteristics:
- The language has one built-in type: the boolean type called 'bit'. It also has one built-in operator, the ternary operator: a ? b : c. These work just like in C or similar languages.

- References, like pointers but neither can you change them nor can you assign NULL to them. Need NULL? Borrow from the functional world and use Option, like so: http://alvinalexander.com/scala/using-scala-option-some-none-idiom-function-java-null . Remember, we will optimize this for you (e.g. it becomes a regular pointer that can be null in the compiled sources). We'll also give you a nice memory-manipulation API if you like playing dangerous, unless you're in a sandbox environment of course.

- Also, there is support for tuples, that can contain an ordered set of bits, references or other sub-tuples. With some imagination, these go beyond simple vectors and matrices, becoming complex types as described below.


- The block:

The block contains code. It's like a C-like function, but without a name. In other words, a lambda-function.
-- Degree 1: 1^{ config.load userFile } or just { config.loadUser }.

-- Degree 2+: Macros-on-steroids that run at compile time: 2^{ config.mainSymbol }.

-- Degree 0: Strings: 0^{ abc } or just "abc" are like C-strings, but only available to degree 2-blocks and beyond. The first one being neat for embedding other languages, like SQL. It's up to the programmer to implementing C-strings, UTF-8 arrays, sprintf, shader pre-compilation or whatever suits the application. However, we give you a standard library with UTF-16 as standard.

Blocks will be able to take variables as arguments and return data. If these variables are supposed to be saved somewhere, that has to be specified (it means the compiler has to use another allocator than the internal stack-based one, like the malloc allocator in the standard library or the GPU-buffer allocator in OpenGL).

- Types with symbols. While recursive tuples make up the data structure/composition, the most important part of any non-trivial program is organization. Types links tuples of bits and references to symbols. A symbol is either a method or an operator (they're mostly the same in Bitlang). The symbol consists of a degree-1+ block. If it is a degree-2+ block, it is also specified if a value or an expression is needed. If it is an operator, it is specified if it's binary/unary and which precedence it takes. Further information on this subject will come in a separate post.

- There will be a scope-system (for variables) similar to the JavaScript prototype chain. Scopes can be bound by higher-degree blocks for method calls. The default is what you would expect, inline-blocks inherit from outer blocks. But, the scope may be replaced or mixed in for some contexts. It's important this can only be done in a way that cannot confuse programmers, maybe by using a prefix or similar. Type systems can use this to create magic this, parent/super etc. variables.

The Standard Library:

- Contains most of what's considered "the core language", in other languages. For example, a standard implementation of classes goes in here (but you can use your favourite implementation if you want, like ObjC's or JavaScript's). Another example is the integer types, uint64 and the like. Of course, these are heavily optimized at compile time.

- The problems goes into the library rather than the spec. - we can throw out problematic features without ruining compiler infrastructure in the future. Check out Google's C++ style guide and you will have a good laugh, it's mostly about the hundreds of features you're not allowed to use. Also, check out the numerous Java Collection frameworks out there that struggle with generics, or the dependency injection libraries that almost work with a lot of runtime reflection magic. Then look att the success of the Boost library. It's easy to see that flexibility matters.

- A clear API. Remove the confusion! Ruby does this good. No abbreviations, good convention like always apply (no PHP needle, haystack chaos), use of operators avoided to lessen confusion. Try to reuse conventions from other languages unless they're stupid. Example: Rather use myInteger.logicalRightShift 3 than myInteger >> 3 or myInteger >>> 3 depending on which language to mimic (one of them means that sign extension is used, but which one is different in different languages).

The Package System:

This will come later. However, a package system is not a bad idea for keeping track of external dependencies. The standard library might use this to organize its parts. New features might be added as extensions that can later be included in the core standard library distribution.