Issue Type
Other specification error
Description
This isn’t a bug in the spec, more a data point about how LLMs interpret empty arrays in TOON. For possible consideration in future iterations of this spec.
When encoding empty arrays, TOON produces:
$ npm ls @toon-format/toon
project0.0.1 /Users/dev
└── @toon-format/toon@1.2.0 -> ./../../node_modules/.pnpm/@toon-format+toon@1.2.0/node_modules/@toon-format/toon
$ node
> const { encode } = require('@toon-format/toon');
> console.log(encode({ log: { matches: [] } }))
log:
matches[0]:
When I ask LLMs "were there any matches?", most respond with something like "yes (though it looks undefined / empty)". They seem to treat matches[0] as an array with a empty element at index 0.
Since TOON is explicitly designed as an LLM-friendly text format, this might be useful to re-consider.
Specification Reference
Array header syntax
Current Behavior
Expected Behavior
Example
Impact
Devs need to work around this, eg
- giving LLM instructions on how to interpret TOON syntax
- replacing empty arrays with more explicit language like:
> console.log(encode({ log: {matches: 'none'}}))
log:
matches: none
Proposed Fix
No response
Additional Context
No response
Checklist
Issue Type
Other specification error
Description
This isn’t a bug in the spec, more a data point about how LLMs interpret empty arrays in TOON. For possible consideration in future iterations of this spec.
When encoding empty arrays, TOON produces:
When I ask LLMs "were there any matches?", most respond with something like "yes (though it looks undefined / empty)". They seem to treat matches[0] as an array with a empty element at index 0.
Since TOON is explicitly designed as an LLM-friendly text format, this might be useful to re-consider.
Specification Reference
Array header syntax
Current Behavior
Expected Behavior
Example
Impact
Devs need to work around this, eg
Proposed Fix
No response
Additional Context
No response
Checklist