tree-sitter-netlinx

NetLinx grammar for tree-sitter.

NOTE ⚠️ 🚧

This is a work in progress. Once the grammar is complete, a release will be made.

At this point the grammar is mostly complete. Work is now focused on testing and fixing any bugs.

Contents 📖

• What's Working ✅
• Install ⚡
  • Node.js (npm)
  • Rust (Cargo)
  • Python (pip)
  • Manual Installation
• Design 🎨
  • Permissive Parsing
  • Syntax vs. Semantics
  • Examples of Accepted Patterns
  • Flexibility Over Semantic Correctness
• Team ⚽
• Contributors ✨
• LICENSE ⚖️

What's Working ✅

• Expressions
  • ✅ Binary Expressions
  • ✅ Bitwise Expressions
  • ✅ Bitwise Word Expressions (band, bor, bxor, bnot, lshift, rshift)
  • ✅ Unary Expressions
  • ✅ Update Expressions
  • ✅ Assignment Expressions
  • ✅ Devchan Expressions
  • ✅ Devchan Range Expressions
  • ✅ Comparison Expressions
  • ✅ Logical Expressions
  • ✅ String Expressions
  • ✅ Function Call Expressions
  • ✅ Device Expressions (0:first_local_port+1:1, dvPort.NUMBER:dvPort.PORT:dvPort.SYSTEM)
  • ✅ Parenthesized Expressions
  • ✅ Subscript Expressions
  • ✅ Comma Expressions
• Statements
  • ✅ Expression Statements
  • ✅ Compound Statements
  • ✅ Return Statements
  • ✅ Break Statements
  • ✅ Continue Statements
  • ✅ If Statements
  • ✅ While Loops
  • ✅ For Loops
  • ✅ Switch/Case Statements
  • ✅ Select/Active Statements
  • ✅ Create Buffer Statements
  • ✅ Create Multi Buffer Statements
  • ✅ Clear Buffer Statements
  • ✅ Wait Statements
  • ✅ Wait Until Statements
  • ✅ Cancel Wait Statements
  • ✅ Cancel Wait Until Statements
  • ✅ Cancel All Wait Statements
  • ✅ Cancel All Wait Until Statements
  • ✅ Break Statements
  • ✅ Section Statements
  • ✅ Program Name
  • ✅ Module Name
  • ✅ Send String Statements
  • ✅ Send Command Statements
  • ✅ Send Level Statements
  • ✅ Devchan Operation Statements (ON, OFF, TO, MIN_TO, PULSE, etc)
  • ✅ Call Statements (for legacy DEFINE_CALL functions)
• Declarations
  • ✅ Define Function Definitions
  • ✅ Define Library Function Declarations
  • ✅ Define Call Definitions
  • ✅ Variable Declarations
  • ✅ Constants Declarations
  • ✅ Type Declarations
  • ✅ Module Definitions
  • ✅ Combine Definitions
  • ✅ Connect Level Definitions
  • ✅ Toggling Definitions
  • ✅ Mutually Exclusive Definitions
• Events
  • ✅ Button Events
  • ✅ Channel Events
  • ✅ Level Events
  • ✅ Data Events
  • ✅ Timeline Events
  • ✅ Custom Events
• Literals
  • ✅ String Literals
    • ✅ Single Quoted String Literals
    • ✅ Escape Sequence for Single Quotes ('')
  • ✅ Number Literals
    • ✅ Decimal
    • ✅ Hexadecimal
    • ✅ Floating Point
  • ✅ Device Literals
• Comments
  • ✅ Single Line Comments
  • ✅ Multi Line Comments (C Style /* */)
  • ✅ Pascal Comments ((* *))
• Preprocessor
  • ✅ Define
  • ✅ Include
  • ✅ Warn
  • ✅ Disable Warning
  • ✅ If Defined
  • ✅ If Not Defined

Install ⚡

Node.js (npm)

For JavaScript/Node.js projects:

npm install tree-sitter-netlinx

# or

yarn add tree-sitter-netlinx

# or

pnpm add tree-sitter-netlinx

Rust (Cargo)

For Rust projects:

cargo add tree-sitter-netlinx

Python (pip)

For Python projects:

pip install tree-sitter-netlinx

Manual Installation

If you want to install the grammar manually, you can clone the repository and build it yourself:

git clone https://github.com/Norgate-AV/tree-sitter-netlinx
cd tree-sitter-netlinx
npm install
npx tree-sitter generate

Design 🎨

The grammar is designed to be as accurate as possible, while also being as flexible as possible.

Permissive Parsing

The grammar is intentionally permissive, allowing it to parse syntactically valid but semantically questionable code. This approach enables:

• Better error recovery during editing
• A more forgiving experience during development
• The ability to parse incomplete or incorrect code
• Better syntax highlighting and code navigation

Syntax vs. Semantics

As a parsing tool, tree-sitter focuses on syntactic structure rather than semantic validity:

• The parser will accept constructs that are syntactically correct but might fail during compilation
• Semantic validation should be handled by the NetLinx compiler or separate analysis tools
• This separation allows the grammar to be more stable and maintainable

Examples of Accepted Patterns

The parser will accept patterns that the NetLinx compiler might reject:

• Declarations with inconsistent or incomplete type specifiers
• Mixed implicit and explicit typings
• Unusual combinations of modifiers
• Devchan range expressions used with devchan operations

Flexibility Over Semantic Correctness

The parser deliberately prioritizes syntactic flexibility over strict semantic validation:

• Section-Independent Parsing: Declarations can appear anywhere in the code, even outside their semantically correct sections. The parser doesn't enforce section-specific constraints that the NetLinx compiler would apply.

• Context-Free Analysis: Device definitions, constants, and variables are parsed based on their syntactic structure rather than their semantic context. For example, device definitions in a DEFINE_DEVICE section are parsed as standard assignment expressions.

• Support for Implicit Typing: The parser accommodates NetLinx's implicit typing behaviors. In NetLinx, when type declarations are omitted, the compiler applies implicit types—INTEGER for regular variables and CHAR for array variables.

Examples:

DEFINE_CONSTANT
FOO = 1  // Parsed as an assignment expression rather than a specialized constant declaration

DEFINE_VARIABLE
bar = 1  // Parsed as an assignment expression
         // NetLinx compiler would implicitly type this as INTEGER

baz[10]  // Parsed as an identifier with subscript
         // NetLinx compiler would implicitly type this as CHAR array

This approach enables more resilient parsing during code editing and provides better syntax highlighting and tooling support, even for incomplete or semantically imperfect code. Semantic validation is intentionally left to the NetLinx compiler or separate analysis tools.

Team ⚽

This project is maintained by the following person(s) and a bunch of awesome contributors.

Damien Butt

Contributors ✨

Thanks go to these awesome people (emoji key):

This project follows the all-contributors specification.

Contributions are welcome! Please fork and open a pull request if you have any suggestions or improvements.

Any help would be greatly appreciated.

LICENSE ⚖️

MIT