You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Status should be based primarily on the current source code and automated tests. If this checklist disagrees with implemented parser behavior or test coverage, inspect the source/tests first and then update this document to match.
Legend
Status: (and Table Title)
✅ All sub-features done
🚧 Partially or WIP (Work in Progress)
🔲 Not started
❌ Not currently
Impl.: (parsing and logic implemented)
✔️ Yes, done
🚧 Partially or WIP (Work in Progress)
🔲 Not started
❌ Not currently
Test: (unit/integration test, NOTE: Smoke tests not counted!)
✔️ Yes, done
🚧 Partially or WIP (Work in Progress)
🔲 Not started
❌ Not currently
Verf: (verification)
✔️ Yes, done
🚧 Partially or WIP (Work in Progress)
🔲 Not started
❌ Not currently
Progress Overview
#
Status
Section
1
✅
Core Parsing / Basic Members
2
✅
File Structure & Errors
3
✅
Basic / Simple Literals
4
✅
Comments + Disable line
5
✅
Extended Parsing
6
✅
Number Literals
7
✅
String Literals
8
✅
Object Literals
9
✅
List Literals
10
🚧
Special & Validation Modes
11
✅
Public API & Options (ParseOptions)
12
🔲
Reserved/Advanced Features
✅ — 1. Core Parsing / Basic Members
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
Simple (key and header) identifiers
✅
✅
✅
✅
Non backticked
Identifier validation rules
✅
Reject invalid simple identifiers and invalid backticked identifiers
✅
✅
✅
Simple identifiers must not start with digits and must not contain spaces, hyphens, dots, slashes, colons, or non-ASCII letters. Backticked identifiers reject raw tabs, newlines, carriage returns, raw backticks, trailing backslashes, and invalid escape-like sequences. Covered by helper unit tests and section-header integration tests for dotted names.
Throw error if using section repeating markers higher than supported
✅
Per spec only nesting levels 1–9 supported with repeating markers, e.g. ^^^^^^^ is invalid
✅
✅
✅
For higher levels, the shorthand marker must be used instead
Type inference
✅
String, integer, float, boolean, null
✅
✅
✅
Based on value syntax
Key-value pairs
✅
Simple assignment key = value
✅
✅
✅
Core syntax
Assignment/member same-line rule
✅
KEY, =, and the first value token must appear on the same logical line
✅
✅
✅
Implemented by the grammar rule member : KEY EQ value? and covered by a focused integration test for key = followed by a value on the next line.
Section nesting: Going deeper
✅
Sub-sections with increased nesting, throw error if jumping over section levels
✅
✅
✅
Must increment exactly one level at a time. E.g.: `^^` → `^^^` but not `^^` → `^^^^`.
Section nesting: Going shallower
✅
Sub-sections with decreased nesting
✅
✅
✅
May drop directly to any previous level. E.g.: `^9` → `^^` or `^9` → `^`.
Unique keys (per section)
✅
Reformat/emit error/warning
✅
✅
✅
Enforce per nesting level
Duplicate sections under same parent
✅
Same section name at the same nesting level and parent
✅
✅
✅
Lenient mode: first section wins and later duplicate section blocks are ignored with warning. Strict mode: error. Must not merge, overwrite, or reinterpret duplicate section contents.
✅ — 2. File Structure & Errors
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
UTF-8 Encoding
✅
BOM detection
✅
✅
✅
Must handle UTF-8 with/without BOM
Shebang handling
✅
#! on first line
✅
✅
✅
Ignored by parser
@yini optional marker/keyword
✅
E.g. @yini, @YINI, etc
✅
✅
✅
Case-insensitive
Check file extension .yini
✅
Case-insensitive, otherwise throw error
✅
✅
✅
Naming convention
Throw error if parsing some garbage
✅
⚠️ Including trying to parse nothing ("") or invalid characters, etc.
➖
✅
✅
Throw error if parsing unknown file name
✅
⚠️ Including trying to parse a blank file name (""), etc.
➖
✅
✅
✅ — 3. Basic / Simple Literals
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
Integer and float numbers
✅
123, 3.14
✅
✅
✅
Basic numbers
Basic strings, single and double quoted
✅
'Hello', "World", including handle slash, backslash, and inline quotes
✅
✅
✅
Basic strings without prefix
All Boolean literals
✅
true, false, Yes, No, ON, OFF
✅
✅
✅
⚠️Case-insensitive
(Explicit) All Null literals
✅
null, NULL, Nulletc
✅
✅
✅
⚠️Case-insensitive
✅ — 4. Comments + Disable line
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
Full-line comment with `;`
✅
; Line comment
✅
✅
✅
Inline comment with `#`, `//`
✅
# Comment // Comment
✅
✅
✅
# always begins a comment outside string literals; no whitespace is required.
Block comment
✅
/* ... */
✅
✅
✅
Disable line with `--`
✅
--This line is ignored
✅
✅
✅
For temporarily ignoring valid code
Ignore comments or disable line when parsing/extracting entities such section names, keys and other identifiers or values
✅
E.g. ^ App // Comment should extract section name = "App" and not "App // Comment", etc
✅
✅
✅
⚠️ Easy to forget trimming away these
✅ — 5. Extended Parsing
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
Backticked keys (identifiers)
✅
`this is a key`
✅
✅
✅
Key name in members
Backticked section headers (identifiers)
✅
^ `My Section`
✅
✅
✅
Section names with spaces etc.
Standard/basic/classic section marks (^, §, >, <)
✅
✅
✅
✅
Primary marker is ^. Alternatives are §, >, and <. Repeated form supports levels 1–9.
Numeric shorthand section marker (^7, etc.)
✅
^7 Section
✅
✅
✅
Arbitrary nesting; requires horizontal space after the numeric shorthand; thus ^7Section is incorrect.
Maximum section depth
✅
Maximum supported section depth is 255
✅
✅
✅
Parser/validator rejects section depths above 255. Tests cover parsing through the maximum supported depth and rejecting max depth + 1 without skipping intermediate section levels.
(Implicit) Null
✅
Empty value
✅
✅
✅
⚠️ Only if option.treatEmptyValueAsNull = 'allow' (This is default in lenient mode, disallow in strict mode)
Members outside any explicit section
✅
key = 123
✅
✅
✅
⚠️ Mounted directly on the parsed result, or under an implicit base object if required by the implementation
Multiple top-level sections
✅
^ Title1
^ Title2
✅
✅
✅
⚠️ Mounted directly on the parsed result as separate top-level objects in lenient mode; invalid in strict mode.
Section marker separators
✅
^^_^^_^ Section, ^^^_^^^_^^^ Section
✅
✅
✅
Underscores may appear only between repeated occurrences of the same section marker. They do not count toward section depth.
✅ — 6. Number Literals
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
Negative numbers
✅
-123, -9.22
✅
✅
✅
Both ints and floats
Exponent notation numbers
✅
3e4
✅
✅
✅
Incl. neg. exp.
Binary numbers
✅
0b1010, %1010
✅
✅
✅
⚠️ Including alternative notation with %
Octal numbers
✅
0o7477
✅
✅
✅
8-base
Duodecimal (dozenal)
✅
0z2EX9, 0z2AB9X = A = 10, E = B = 11
✅
✅
✅
12-base
Hexadecimal numbers
✅
0xF390, hex:F390, 0X3fa
✅
✅
✅
⚠️ 16-base. # is no longer a hexadecimal prefix; use 0x... or hex:....
Digit separators
✅
1_000, 0x_ab_cd, 0b_1010, hex:_FF
✅
✅
✅
Underscores are allowed after base prefixes and between digits, but not at the end or doubled.
✅ — 7. String Literals
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
Raw string (default)
✅
'...', "...", no escapes
✅
✅
✅
Single line, enclosed in ' or "
Classic string (C-string)
✅
C'...', C"...", with escapes
✅
✅
✅
Single line, escape codes, prefixed either with C or c
Hyper string (H-string)
✅
H'...', H"..."
✅
✅
✅
Removed after RC5 to simplify the language core and reduce parser complexity. Not supporting H-strings is correct for RC6.
Triple-quoted (raw)
✅
"""...""", multi-line
✅
✅
✅
Raw by default
C-Triple-quoted
✅
C"""...""", with escapes
✅
✅
✅
Multi-line, supports escapes
String concatenation
✅
"foo" + 'bar'
✅
✅
✅
All string types
Escape sequence validation
✅
Reject invalid escapes such as \z, \o378, invalid Unicode scalar values, and surrogate code points
✅
✅
✅
Escape sequences are valid only in C-Strings and C-Triple-Quoted Strings. Implemented in src/parsers/parseString.ts and covered by Classic and C-Triple string tests.
Preserve escape-like sequences in raw strings
✅
Raw strings do not interpret escapes
✅
✅
✅
Backslashes are ordinary characters in raw strings; raw string tests cover this behavior.
Lenient scalar-to-string concatenation
✅
"enabled=" + true, "value=" + null
✅
✅
✅
Lenient mode only. Strict mode allows concatenation only between string literals.
Multi-line concatenation after +
✅
"a" + "b"
✅
✅
✅
A line break may occur after +.
Reject line break before +
✅
"a" + "b"
✅
✅
✅
The + operator must appear on the same logical line as the preceding operand.
Reject numeric-only plus expressions
✅
1 + 2 + 3
✅
✅
✅
YINI does not define numeric addition.
Reject lists/objects as concatenation operands
✅
"x" + [1, 2], "x" + { a: 1 }
✅
✅
✅
Lists and inline objects must not be used as concatenation operands.
✅ — 8. Object Literals
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
Objects
✅
{ key: value, ... }
✅
✅
✅
Inline, supports nesting, object member separators, and trailing comma handling.
Empty object literal
✅
{} and { }
✅
✅
✅
Implemented by lexer/parser empty-object handling and covered in lenient and strict object literal integration tests.
Nested objects inside objects
✅
Objects themselves are literals and can be nested
✅
✅
✅
Nested objects inside lists
✅
Objects themselves are literals and can be nested
✅
✅
✅
Inline object member separators
✅
{ key: value } and lenient { key = value }
✅
✅
✅
Recognizes both : and = as inline object member separators.
In lenient mode, both are accepted for flexibility.
In strict mode, = is rejected as a syntax error to enforce the canonical key: value form.
Duplicate inline object member keys
✅
{ a: 1, a: 2 }
✅
✅
✅
Lenient mode: first member wins and later duplicates are ignored with warning. Strict mode: error. Implementations must not silently overwrite. Implemented in the AST builder and covered by object literal tests.
Object member value same-line rule
✅
a: 1 valid, but newline after : before value is invalid
✅
✅
✅
Inside inline objects, the value must begin on the same logical line as the object member separator. Enforced by the grammar rule object_member : KEY object_member_separator value.
Object opening brace same-line rule
✅
obj = { ... }; newline after = is not an object value
✅
✅
✅
The opening { must appear on the same logical line as =. Enforced through the same-line member/value grammar.
✅ — 9. List Literals
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
Bracketed lists ([])
✅
key = [a, b, c]
✅
✅
✅
Trailing comma allowed and is ignored (lenient only)
Empty list literal
✅
[]
✅
✅
✅
Implemented by lexer/parser empty-list handling and covered by focused lenient and strict integration tests.
Colon-list syntax removed / not supported
✅
Old colon-list syntax must not be accepted; bracketed lists are the supported form
✅
✅
✅
The RC6 grammar only defines bracketed lists. Covered by a focused invalid integration test proving colon-list syntax is rejected.
Nested lists inside lists
✅
Lists themselves are literals and can be nested
✅
✅
✅
Nested lists inside objects
✅
Lists themselves are literals and can be nested
✅
✅
✅
List opening bracket same-line rule
✅
items = [ ... ]; newline after = is not a list value
✅
✅
✅
The opening [ must appear on the same logical line as =. Enforced through the same-line member/value grammar.
🚧 — 10. Special & Validation Modes
Sub-Feature
Status
Details
Impl.
Test
Verf
Notes
Document terminator /END
✅
/END, non-case-sensitive
✅
✅
✅
Case-insensitive terminator implemented. Missing-terminator behavior is controlled by requireDocTerminator: optional, warn-if-missing, or required.
Lenient mode (default)
✅
Allows trailing commas, blank/null values, multiple top-level sections, root-level members, and warning-based recovery where allowed by the rules.
✅
✅
✅
Default parser mode.
Strict mode
✅
Enable stricter structural validation and stricter default rule behavior. In strict mode, there must be exactly one explicit top-level section. Some strict-related rules may also be overridden by parse options.
✅
✅
✅
Strict-mode validation for the RC6 parser surface is implemented. Some strict-related behavior remains configurable through rule options such as requireDocTerminator and treatEmptyValueAsNull.
@yini strict / @yini lenient mode declarations
✅
Optional mode declaration after the YINI marker
✅
✅
✅
Declaration does not switch parser mode.
@yini strict parsed in lenient mode must produce a mode-mismatch error.
@yini lenient parsed in strict mode must remain valid, but must produce a mode-mismatch warning.
Give error on empty document in strict mode
✅
Document contains only whitespace, comments, and/or disabled lines
✅
✅
✅
Must result in an error.
Give warning on empty document in lenient mode
✅
Document contains only whitespace, comments, and/or disabled lines
✅
✅
✅
Must not fail, SHOULD produce a warning diagnostic that the file has no meaningful content.
Optional Bail/Abort sensitivity levels
✅
Level 0 = Ignore errors and try parse anyway (may remap faulty key/section names).
Level 1 = Abort on errors only.
Level 2 = Abort even on warnings.
✅
✅
✅
Detect multiple @yini
✅
If using multiple @yini should warn in lenient and cause error in strict mode
✅
✅
✅
This requires updates in the grammar and its parser logic
Only one document terminator
🚧
Reject multiple /END markers
✅
🔲
🔲
Grammar and AST builder logic enforce a single document terminator position. Add a focused regression test for multiple /END markers.
Strict-mode filename suffix .strict.yini
🔲
Optional filename convention for files intended to be parsed in strict mode
🔲
🔲
🔲
Does not switch parser mode. Implementation SHOULD warn if a .strict.yini file is parsed in lenient mode.
Meta: Count num of sections
🚧
Meta info
✅
🔲
🔲
Assigned by the AST builder; dedicated count assertion test is still skipped.
Meta: Count num of members
🚧
Meta info
✅
🔲
🔲
Assigned by the AST builder; dedicated count assertion test is still skipped.
✅ — 11. Public API & Options (ParseOptions)
Option
Status
Details
Impl.
Test
Verf
Notes
tools/yini-test-adapter.ts adapter contract
✅
Adapter behavior for external conformance/tooling test runners.
✅
✅
✅
Defines command-line behavior, input handling, parser mode selection, and JSON output contract for yini-test integration.