Better format

[porky11]

if you know a better format, tell me!

I'd use just s-expressions or an s-expression based format

Short explanation:
This is an s-expression: (tag a b c...)
In programming languages, tag represents
In most programming languages, you would write tag{a, b, c...} or tag(a, b, c...)

The advantages of using s-experssions instead of other formats:

• no need for unnecessary syntax
  You normally don't use commas for separating values and you also don't use colons for key-value pairs.

• obvious meaning
  when having a tag instead of different kinds of bracket pairs, one cannot get confused when also dealing with other data formats.
  It's not necessary to add the quotation marks, if the string does not have spaces.

• expressiveness/flexibility
  It's easy to create some more complex syntax for different tags.

• extensibility
  The language can be extended to support new kinds of data structures, when needed, but also include some more general data structures, that are allowed to be parsed into any kind of data structure

It's not important, that you write the s-expressions like this: (tag ...)
Wrtiing tag(...) could be preferable to most people.
In this case, spaces are not allowed between the tag and the brackets, else commas may be necessary.

I would include following tags:

• list: list of objects of the same type
• tuple: tuple of objects of different types
• struct: tuple with named fields
• map: map with named fields
• variant: variant type with named variants

Key-value pairs, the arguments of struct, map and variant, could be represented in different ways.
Either by plists ((key1 value1 key2 value2 ...)), by alists (((key1 value1) (key2 value2) ...)) or by using additional syntax (either (key1 : value1 key2 : value2) or (key1 value1, key2 value2)).

Instead of having to write tags such as struct and map, it may be more reasonable to just use simpler tags like single letters or symbols.
Having different kinds of brackets also isn't a bad idea instead of tags, but only as an addition for extensibility.
There may also be tags that don't require just argument lists nor key-value-pairs.

The example scene could be represented this way, when using plists for key-value-pairs:

struct(
    materials map(
        metal struct(reflectivity 1.0)
        plastic struct(reflectivity 0.5)
        )
    )
    entities list(
        struct(
            name hero
            material metal
        )
        struct(
            name monster
            material plastic
        )
    )
)

A notation, that's even simpler, would be the scopes notation, like it is in the programming language scopes.
It uses s-expressions, but they are written in some Indentation based syntax, like python.

Using the same s-expression tags, but a different format for key value pairs, like it's commonly used in scopes, it would look like this:

struct # comments look like this
    materials =
        map
            metal =
                struct
                    reflectivity = 1.0
            # bracket based syntax is still supported in case you don't want to waste lines
            plastic = (struct (reflectivity = 0.5))
    entities =
        list
            struct
                name = "hero"
                material = "metal"
            struct
                name = "monster"
                material = "plastic"
# another advantage: when using indentation anyway, you don't have closing brackets here

This format is already parseable into s-expressions (with typed values) from scopes, so it's already easy to use such a format also for config files there.
Writing config files in this format is very simple, especially when already using scopes (which uses the same syntax) for real programming

So that's what I think, is a better format

[torkleyy]

Thanks! Added to the wiki.