erick-alcachofa
5762497f56
Signed-off-by: erick-alcachofa <erick@artichoke.dev> Overhaul the expression parsing mechanism to utilize a Pratt (top-down operator precedence) parser. This change provides a more scalable and maintainable way to handle operator precedence and associativity compared to standard recursive descent. As part of this transition, the nomenclature for operators has been refined to reflect their position in the grammar (Prefix, Infix, Postfix) rather than their arity. * Renamed `UnaryOperator` and `UnaryExpression` to `PrefixOperator` and `PrefixExpression`. * Renamed `BinaryOperator` and `BinaryExpression` to `InfixOperator` and `InfixExpression`. * Renamed `ScopeAccessExpression` to `ModuleAccessExpression`. * Introduced `PostfixOperator` enum and associated logic for function calls, slicing, and reflection attributes. * Updated `toDot.cpp` and `toString.cpp` to support the new node types and renamed operators. * Added `Pratt.hpp` and `Pratt.cpp` to define `BindingPower` and map operators to their respective precedence levels. * Added `Operators.cpp` to handle token-to-operator mapping and classification (isPrefix, isInfix, isPostfix). * Refactored `Parser::parseExpression` to implement the core Pratt loop using binding power comparisons. * Moved literal parsing logic into a dedicated `Literals.cpp`. * Implemented explicit parsing methods for `Integer`, `Float`, `Char`, `String`, `Boolean`, and `Null` literals. * Added support for `this` and `_` (underscore) as identifier expressions. * **Prefix**: `!`, `-`, `~`, `&` (MemPtr), `*` (DerefPtr). * **Infix**: Arithmetic, Comparison, Bitwise, Logical, and all Compound Assignments. * **Postfix**: `()` (Call), `[]` (Slice/Access), `.#` (Slice length), `.*` (Slice pointer), and `.@` (Reflection). * **Missing Literals**: Struct literals and Array literals are not yet implemented in the new parsing flow. * **Node Specialization**: `MemberAccess`, `PointerMemberAccess`, and `ModuleAccess` currently use generic infix logic and need to be migrated to their specific AST node types. * **Error Handling**: Literal parsing (specifically `std::stold` and `std::stoul`) needs safety checks to prevent potential exceptions during conversion. * **Diagnostics**: Refine the error message for unexpected tokens in postfix expressions to explicitly list supported operators. * **Generic Ambiguity**: Generic type/function instantiation currently causes parsing conflicts with comparison operators (e.g., `Foo<T>`). This is a known issue that will be resolved by transitioning the grammar to a turbofish-style `::<...>` syntax.
⚠️ WIP Highly Experimental Project
- The language, compiler, and tools are under active development and may be very unstable.
- There will likely be breaking changes and periods where no work is done on the project.
The artichoke Programming Language
artichoke is a modern, statically-typed programming language designed to
satisfy my personal preferences and requirements for programming, combining the
low-level control and powerful modern features like a robust type system,
generics, integrated error handling, and a clean, ergonomic syntax.
The goal of artichoke is to provide a language that is simple, safe, and
productive for programming, eliminating common pitfalls without sacrificing
performance or control.
For a detailed guide to the language, please see the project wiki.
Core Philosophy & Features
artichoke is built around a few core principles to create a safer, more
productive programming experience:
- Explicitness: Type conversions and error handling are explicit.
- Safety: Non-nullable pointers, a robust type system, and deterministic resource management are prioritized.
- Modern Ergonomics: Features like generics, defer, and a clean module system reduce boilerplate and improve readability.
The language includes a powerful generic type system, first-class error handling, a full suite of control flow statements (including match), a true module system, and compile-time reflection.
Project Status
artichoke is currently in the design and grammar-specification phase. The
grammar is stable, and the next step is the implementation of a compiler
(parser, semantic analyzer, and code generator).
Building from Source
# Get the source code
git clone https://git.artichoke.dev/me/artichoke-lang.git
# Configure cmake
# Optionally add -DENABLE_TESTING=ON for building tests
cmake -DCMAKE_BUILD_TYPE=Release -S . -B build
# Build the project
cmake --build build
# Run the binary
./build/frontend/artichoke-c
# Run the tests if enabled
ctest --test-dir build/tests --output-on-failure
# Install if wanted
cmake --install build --prefix=/usr/local
# Run the installed binary
arti-c
Contributing
The artichoke project is hosted on a personal, self-hosted Gitea instance. If
you are interested in contributing, you have two options:
- Request an Account: Please contact support@artichoke.dev to request an account on the Gitea instance.
- Submit Patches: Alternatively, you can send patches or diffs directly to the same email address.
In all cases, proper attribution will be given for your contributions in the source files and/or the project wiki.
License
This project is licensed under the GNU Affero General Public License v3.0. The full license text can be found in the LICENSE file in this repository.