The Trio documentation describes rules for nesting Dicts and Grids, both in an easy-to-read, multi-line, human readable format.

I was wondering if a similar, multi-line, format exists for Lists?

In JSON, a List of Objects may be expressed like this:

{
    "name" : "Outer Object",
    "list" : [
        {
            "name" : "item 1",
            "val0" : 1,
            "val1" : 2,
        },
        {
            "name" : "item 2",
            "val2" : 3,
            "val3" : 4,
        },
        {
            ...
        }
    ]
}

Substituting Objects for Dicts, how would I represent similar in a Trio file?

If not possible today, would Project Haystack consider adding an easy-to-read, multi-line format for Lists?

Or is the answer simply, "Project Haystack is not for this kind of data."?

I brainstormed with Jason about it this week because we need to switch the children protos in defs to be more formally defined as a list of dicts. What we came up with just normal Zinc/JSON format with following rule:

1. Opening line starts with "[" or "{"
2. Rest of the list/dict is indented two lines like multi-line strings

That is still easy to parse, easy to write, and easy to read:

def: ^someExample
children: [
  {this, is, one, dict},
  {here, is, another},
  ]

Is this enhancement for Trio just for a list of Dicts or does it apply to a list of any time of value?

Also the format of the Dict is incorrect if we're using Zinc. The example has commas. Is this intentional or a mistake in the example?

A dict in Zinc should be...

{this is one dict}

...instead of...

{this, is, one, dict}

Is this enhancement for Trio just for a list of Dicts or does it apply to a list of any time of value?

I think any zinc encoded value. What I did was suck the entire block of indented text in stripping newlines and then parsed it as normal zinc

The example has commas. Is this intentional or a mistake in the example?

Yes it probably should not have commas. However, I do allow commas in our implementation in nested dicts because they aren't ambiguous and its really annoying to not support them. So I think we should probably make that official in the docs

Ok but let's please make this common to all Dict parsing. It'll be annoying to have one way of parsing a Dict for Trio and another for Zinc.

The spec should also describe the handling of trailing commas for this use case.