linuskmr / fortytwo-lang

FTL is my own programming language. It is inspired by Kaleidoscope, a language introduced in an LLVM tutorial.

fortytwo-lang

fortytwo-lang (FTL) is a programming language. The syntax is a mix of C and Python. It is based on the programming language Kaleidoscope from an LLVM tutorial.

The goal for FTL is to compile to LLVM IR at some point in the future.

See Future Thoughts for how the language could look like later on.

See libftl for ideas regarding the standard library of FTL.

Installation

Running

Sourcecode Documentation

To get the documentation of the fortytwo-lang sourcecode, run the following on your local computer:

cargo doc --document-private-items --open

Reserved keywords

You may don't use these for variable names as they could get keywords in the future.

Memory: ref deref alloc del new default nil

Math: shl shr bitxor bitor bitand

Logic: bool true false and or xor not

Data structures: struct arr const char string list enum

Loops: for in of while

Useful stuff: debug print error def extern

Integer data types: int8 uint8 int16 uint16 int32 uint32 int64 uint64

Floating point number data types: float32 float64

fortytwo-lang's Issues

Update rust project edition to 2021

When Rust Edition 2021 is released in October 2021 try updating the edition in Cargo.toml to 2021.

fortytwo-lang/Cargo.toml

Line 5 in 117553e

edition = "2018"

See https://doc.rust-lang.org/edition-guide/editions/transitioning-an-existing-project-to-a-new-edition.html

Add unary operators

Add unary operators like:

• Double vertical bar |x|, e.g. for getting the length of an array or the positive value of a number
• Unary minus, e.g. -5

---

May be added here as a primary expression:

fortytwo-lang/src/parser/mod.rs

Lines 634 to 641 in d1d81e1

	fn parse_primary_expression(&mut self) -> miette::Result<Expression> {
	match self.tokens.peek() {
	Some(Token { data: TokenKind::Identifier(_), .. }) => self.parse_identifier_expression(),
	Some(Token { data: TokenKind::Number(_), .. }) => Ok(Expression::Number(self.parse_number()?)),
	Some(Token { data: TokenKind::OpeningParentheses, .. }) => self.parse_parentheses(),
	Some(Token { data: TokenKind::If, .. }) => Ok(Expression::IfElse(Box::new(self.parse_if_expression()?))),
	Some(Token { data: TokenKind::For, .. }) => Ok(Expression::ForLoop(Box::new(self.parse_for_expression()?))),
	other => {

Move position attribute to specific type

Instead of using PositionRangeContainer<T>, add a position: PositionRange attribute to T.

Target LLVM instead of C

Maybe use the inkwell LLVM bindings

PositionContainer as Smart Pointer

It might be nice to implement PositionContainer as a smart-pointer-like struct, which combines the position information without extra indirection to reach the inner value. See this gist for a proof of concept implementation:

https://gist.github.com/linuskmr/3bc9561e0dbd5f28a9da3ab6ebe76c27

Return comment token from Lexer

In Lexer::tokenize_next_item() the comment token returned by self.read_comment() has to be returned from tokenize_next_item(). This also enables changing the return type from Option<Result<Token, FTLError>> to ParseResult<Token> and updating the logic in the next() method in the Iterator implementation of Lexer.

Use peek-nth for multiple peeks

The following two functions get parameters passed because their callers need to consume some items from the underlying iterator (the lexer) in order to be able to call the right function.

fortytwo-lang/src/parser.rs

Lines 492 to 495 in 7d35e5c

	fn parse_function_call(
	&mut self,
	name: PositionRangeContainer<String>,
	) -> ParseResult<FunctionCall> {

fortytwo-lang/src/parser.rs

Lines 390 to 393 in 7d35e5c

	fn parse_variable(
	&mut self,
	identifier: PositionRangeContainer<String>,
	) -> ParseResult<PositionRangeContainer<String>> {

That can be avoided by using peek-nth, which allows to peek multiple items in advance.

Operator as min operator

Use operator as min_operator for function call here.

https://github.com/linuskmr/fortytwo-lang/blob/main/src/parser.rs#L78

Better error traceability with anyhow

Consider using anyhow for FTLError.

Move build, test, format to own jobs in CI

In the GitHub CI, move each of the build, test and format steps, that are currently listed as steps in the build job, to an own job, i.e. create a build, test and format job.

Static BinaryOperator HashMap

This HashMap should be static to avoid creating it for every comparison of BinaryOperator.

fortytwo-lang/src/ast.rs

Lines 167 to 173 in d1d81e1

	let mut precedence = HashMap::new();
	precedence.insert(BinaryOperator::Less, 10);
	precedence.insert(BinaryOperator::Greater, 10);
	precedence.insert(BinaryOperator::Add, 20);
	precedence.insert(BinaryOperator::Subtract, 20);
	precedence.insert(BinaryOperator::Multiply, 30);
	precedence.insert(BinaryOperator::Divide, 30);

Maybe use lazy_static.

Fix parse function call

fortytwo-lang/src/parser.rs

Lines 449 to 450 in 667318e

	// TODO: self.parse_argument_list() is not the right function. It parses a list of `name: type`. That is not
	// what we want for a function call.

Add lint job with rust-clippy to CI

Add a lint job to the GitHub CI running rust-clippy.

Add type inference

Add function return type parsing

Add Checker for accessing variables

Currently, statements simply get complied to C code, without any checks whether variables with the specified name are defined. The task is to add a checker that validates creating, accessing and dropping variables. This means that an accessed variable must be defined beforehand and at the creation of a variable, no other variable with the same may exist. This might be even extended to checking that called functions exist and have the correct type signature.

A basic implementation can be found in this gist.

peek_nth in parser for more peeks

https://crates.io/crates/peek-nth

Documentation generator

Implement a parser for documentation comments and a corresponding Markdown documentation generator.

Remove PositionContainer and put position into individual structs

Remove the struct PositionContainer and the file position_container.rs and put the position information into the individual structs.

To be able to access the position from various structs, it makes sense to create a Position struct and a trait Positionable to get the information from the structs:

/// Position in the source code.
struct Position {
    offset: u64,
    len: u64,
    // Maybe also store the filename of this Position
    filename: Rc<String>  // or Path?
}

// To be able to easily convert Position into SourceSpan for error handling.
impl From<Position> for miette::SourceSpan {
    ...
}

/// All structs than store position information should implement this.
pub trait Positionable {
    pub position(&self) -> Position;
}

Use enumerate iter instead of PositionReader

Delete PositionReader and use Iterator::enumerate instead. It simply yields each item with its index, which is actually the position.

Add executable examples

Create executable examples in the examples/ directory. They than can be executed with cargo run --example name.

Move source code to lib/ and bin/ folders

Move source code to lib/ and bin/ folders and adjust Cargo.toml.

Implement Ord for BinaryOperator

Is it possible to implement Ord for BinaryOperator?

fortytwo-lang/src/ast.rs

Line 162 in d1d81e1

impl PartialOrd for BinaryOperator {

FTLError should implement std::error::Error

FTLError should implement std::error::Error. Consider using thiserror.

fortytwo-lang/src/error.rs

Lines 5 to 14 in 117553e

	/// A error occurred while parsing the sourcecode.
	#[derive(Debug, Clone, Eq, PartialEq)]
	pub struct FTLError {
	/// The kind of this error.
	pub kind: FTLErrorKind,
	/// An additional message.
	pub msg: String,
	/// The position this error occurred.
	pub position: PositionRange,
	}