The Acute programming language is an implementation of the Io Programming Language. It is built around a few underlying core principals:

1. Provide a nice implementation written in itself so users of the language can easily make changes and contribute
2. Experiment with any and all things we can to make Io run faster without sacrificing the flexibility of the language

Complete bootstrapping is critical to providing an implementation which, at all levels, is approachable by all users of this language. Let's face it, any language worth its weight in NAND gates is self hosting.

There are many things that may improve speed in Io. Notably, getting rid of a separate argument list and locals, unifying them. Additionally, we may be able to benefit from object versioning in terms of cheap allocations and other benefits related. Perhaps we can even make the system more lazy, or more implement a better concurrency model (where better means something that takes advantage of multiple processors, but is still friendly to use). The point is, there's lots of neat ideas out there, let's try some!

One other area I'd like to focus some serious time on is designing a standard library which is consistent. But this is a lesser priority at this stage of development.

Acute is bootstrapped so that we can write the language in ourself. While it's true, we could just use (Steve Dekorte's IoVM](http://iolanguage.com/) that was seen as less than ideal (dependent on another Io implementation is not a good starting point IMO).

Acute is built in stages, the bootstrap lives at the bottom of the stack, for now. I'll discuss the different parts below. For now, look at this pretty picture of our stack:

This part of the system is responsible for exposing the routines that will let us easily generate machine code, both for our ahead of time compiler, and our just in time compiler.

Caribou is the virtual machine that presently does not exist. However, when it does, its job will be to handle providing critical subsystems, such as the garbage collector, object space, the low level object model itself, and the JIT primitive operations.

Wee is the bootstrap interpreter. All of acute is executed through it at some level. While this is not optimal long term, the long term plans involve separating wee out strictly for compilation help, and adding a virtual machine below it.

Wee is responsible for interpreting code, building an AST, exposing an API through which further layers can deal with, and basically allowing us to write the whole system in itself.

The platform subsystem provides platform agnostic APIs around the low level primitives where appropriate. It will also be responsible at some point in the future, for providing a foreign function interface to Acute.

This subsystem, as its name suggests is responsible for loading the standard library. These are the APIs that programs should execute. By the time this subsystem is loaded, it is ready for evaluating programs.

To build Acute, follow these steps:

1. mkdir build
2. cd build
3. cmake -DCMAKE_C_COMPILER=clang ..
4. make all install

I use C block syntax (an extension Apple created) which is only found in the clang compiler. You'll need it. Any version from 1.0 or up should do, 3.1 is current at the moment.

Copyright (c) 2011-2012, Jeremy Tregunna, All Rights Reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

I'd love to see many people inteterested in helping build this programming language up, and contribute to it ongoing. From documentation to code and even whole subsystems, whatever you can and want to offer, by all means, please let us know.

There are a few things we'd like you to respect though:

1. Develop your feature in a separate branch that I can pull into my repo. Don't clobber the master branch. It's the stable branch;
2. We want to keep a uniform license. As such, by contributing code to us, you are granting us license to distribute your changes under the terms of the MIT license, as found above; and