Add simple tagging

[vagoff]

Maybe it worths to add some simple tagging to the string values? This helps to keep spec simple and keep users of various date formats #263 and regexen #292 happy at the same time.

e.g., "2015-02-06T11:55:12-08:00"

So, allow to tag strings with which describes its format. If parser have no support for this extension it may ignore that and pass string as is, printing warning to stdout.

Nice point of extension.

Fans of NULL may use "", for example.

"aGVsbHA=" as a way to embed binary blobs.

and "/[0-9A-Z_a-z]+/".

You may choose other syntax, e.g., !REGEX"/[0-9A-Z_a-z]+/" or REGEX@"/[0-9A-Z_a-z]+/".
I personally like this:

timestamp = (DATETIME)"Mon, 20 Jan 2014 20:00:00 GMT"

or

timestamp = DATETIME:"Mon, 20 Jan 2014 20:00:00 GMT"
pattern = REGEX:"/[0-9A-Z_a-z]+/"
sshkey = BASE64:"aGVsbHA="
request = JSON:'{"a":true,"b":["",false]}'
limit_bandwidth = { up=Kbit:"8", down=Kbit:"16" }

if allow tags for arbitrary values, we got ability to write

coords = [ tuple:[10,2], tuple:[44,-1], tuple:[91,11]  ]
m = matrix:[ [1,2,3] , [4,5,6] , [7,8,9] ]
expr = term:{head="Mul",args=[term:{head="Add",args=[10,term:{head="Var",args=["x"]}]}]}
mysets = [ set:[1,2,3], set:["a","b",c"], set:[true,false] ]

[ghost]

I think these “type hints” complicate things. Maybe we just need a customizable TOML parser, provide custom functions which comply with the protocols, i.e. array is a container, table is still a key-value table, number is some number, you provide the proper containers and structs, and if everything can work together ... done.

If we just don't like the date-time type, I suppose dropping them, parse the date-time strings ourselves, it is not hard. And transform a date-time string between different format should be trivial in most cases, even if we are so worried about the compatibility between different apps.

[vagoff]

TOML user which is strongly concerned about simplicity may ignore "type hints" completely.

Without type hints it is impossible to construct custom objects/records from TOML fully automatically, in clean and generic way: it needs individual (de)serializer per record, or messing with type introspection, or hacks like JSON hooks which is not very convenient and notably error prone.

Also "type hints" provide nice point of extension for future TOML versions.

[ghost]

I mean that when you give simple hints like REGEX, ISODATE, DATETIME, SET, you still need to consider what is the exact type for a value, i.e. posix regex, extended regex, pcrs, re2, isoXXXX, ordered set, unordered set? What if you want posix regex, but you write the extended one? Need to parse again, or make a bloated parser? So it is still best to get a customizable parser.

[ghost]

Type hints are not necessary if you know the needed types for every “path” (like "first.second.third") beforehand. Then you can tell a customizable parser how to deal with special values. This is enough for simple configuration files. For the complicated ones, you can also wrap them in special objects/tables with the type hints type = "set". It is a flexible method.

[vagoff]

I think type conversion must be done entirely at user level. Generic TOML parser just gives you , pair and let it you consider what to do next on your own.

I think concrete tag specification must not go in TOML. It may go to special TOML Extension Registry standard or be absent at all.

[vagoff]

Type hints are not necessary if you know the needed types for every “path” (like "first.second.third") beforehand.

Yes, but in some programming languages (like e.g., Haskell) it is easy, in more dynamic (e.g., Python) it is a way less convenient. Not being self describing complicates things ;)

Also, to me, having types specified here and there improves readability a lot.

For the complicated ones, you can also wrap them in special objects/tables with the type hints type: "set". It is a flexible method.

Yes. But it disrupts readability and adds clutter.

Compare:

{ "type": "Point", "x": 123, "y": 321 }

and

Point:[123,321]

or (real example!)

{ "type": "box", "x": 321, "y": 123, "width": 44, "height": 500 }

and

box:"44x500+321+123"

(this is ImageMagick geom syntax)

[BurntSushi]

I think this pretty definitively goes against being minimal IMO. Let's just keep things simple. If you need to support a variety of different types then perhaps YAML is a better fit for you.

[vagoff]

Okay! I'll fork and make TOMLX then.

[ghost]

I enjoy this new idea though I think it is not for simple use cases. I feel that it is somewhat like XML.

[vagoff]

Tags won't used if you do not use "nonstandard" data types (only strings/dicts/lists) so simplicity won't hurt.

[vagoff]

To those who want to participate, welcome to https://github.com/vagoff/tomlx

[vagoff]

Oops. In starting message I forgot to mention tags are optional so one may think they are mandatory :/

I hate XML too =)

[mojombo]

Hey @vagoff, thanks for bringing up this idea. I think it's an interesting concept, but I believe it would violate the concept of minimalism that is so important to TOML. Best of luck with INISON!