A compiler for the Adamant language
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
API
AST
Core
Emit.C
Emit
Framework
IL
IntermediateLanguage
Lexing
Metadata
Names
Parsing
Primitives
Scopes
Semantics
Tests.Conformance
Tests.Unit.Core
Tests.Unit.Emit.C
Tests.Unit.Framework
Tests.Unit.Lexing
Tests.Unit
Tokens
adamantc
docs
forge
katas @ c968b2d
runtime
stdlib @ 5a83082
tests @ 2490ff6
.editorconfig
.gitattributes
.gitignore
.gitmodules
Adamant.Tools.Compiler.Bootstrap.sln
Adamant.Tools.Compiler.Bootstrap.sln.DotSettings
README.md

README.md

Adamant Bootstrap Compiler

A bootstrap compiler for the Adamant language. That is, a compiler for a subset of the language that will be used to write the Adamant compiler in Adamant. The compiler currently compiles a small subset of the Adamant language to C.

Project Status: Alpha Active

The compiler is under active development. It is in a very early stage, and there are likely issues and limitations. APIs are subject to frequent breaking changes.

Current Plan

The current plan is to slowly build up functionality by getting a series of katas and small programs working. These will likely be included in the conformance tests. After some very basic programs, various versions of the Fizz Buzz kata will be worked on. As this process is carried out, the plan will be to:

  • Make the Adamant source code as correct as possible given all current ideas on the design of the language with the exception of specific features listed below.
  • Ensure any language features used are in the language reference.
  • If needed, parts of what will be the standard library can be created as compiler intrinsics at first, but they could be replaced with correct standard library code as quickly as possible.

Excluded Language Features

The following features will not be implemented by this compiler even though they are described in the language reference.

  • Meta Functions: Functions which have generic parameters but not regular parameters and are evaluated only at compilet time.
  • Loop Labels
  • Document Comment Validation
  • Full Type Inference: Variable types can be inferred from the type of their initalizer only.

Features Planned for After v1.0

A number of language features are planned for the future but not yet included in the language. For quick reference, SOME of those features are:

Cleanup Tasks

None Currently

Conventions

  • Unit tests are in projects named Tests.Unit.*. This way, it is not inconsistent when further namespaces are nested inside them. If Tests were at the end of the name, then many namespaces would have it at the end, while nested ones would have it in the middle. This also allows conformance and integration tests to be grouped with them by placing them all under the Tests namespace.
  • Reshaper nullability attributes are used to help find issues with null handling. Occasionally, the inference is incorrect because framework calls aren't correctly annotated. In such cases, the AssertNotNull() extension method is used. All methods taking non-null arguments should use Requires.NotNull() to enforce this. This is not necessary on values passed only to the base class constructor as the base constructor is responsible for checking. This null handling helps to support correct by construction and to flag errors as close to their source as possible.
  • Namespace hierarchies are kept fairly flat. This is to avoid issues of needing too many using statements and moving types between them. A namespace should contain all classes that represent the same "kind" of entity without much regard to sub-kinds. Originally, this was not the case. Types were separated into many sub-namespaces, but this ended up being more trouble than it was worth. In practice, one still just used the go to type functionality to find types.