Hi Ulrich,
Good observations! Let me address your points:
1. Naming of encode
You're right that encode operates on SIMPLE_JSON_VALUE. However, we already provide semantic aliases:
encode,
to_toon,
serialize,
compress_for_llm (a_json: SIMPLE_JSON_VALUE): STRING_32
And for string input:
encode_string,
json_to_toon (a_json_text: STRING_32): detachable STRING_32
So to_toon and json_to_toon are already available if you prefer explicit naming. The rationale: TOON's
primary purpose is JSON→TOON conversion for LLM token optimization, so JSON is the expected input.
2. Direct TOON type builders
This is a valid feature request. Currently, you must build JSON first, then convert. A direct TOON_BUILDER would be useful:
-- Proposed future API:
create builder.make
builder.add_string ("name", "Alice")
builder.add_integer ("age", 30)
builder.add_array ("items")
.row ("A1", 10)
.row ("B2", 20)
builder.to_string
I'll add this to the roadmap. For now, use simple_json to build the structure, then toon.encode.
3. Formal specification
TOON has an external specification. See the EIS links in the class header:
- Spec:
https://github.com/toon-format/spec - Format:
https://toonformat.dev/ 4. Complex examples
Fair point. The README shows basic examples. I'll add a cookbook page with realistic scenarios (nested structures, mixed arrays, edge cases).
Thanks for the feedback—direct builder API is a good idea.
Larry