Difference between empty tables and "implicit" tables makes parser logic harder

[cies]

I'm talking about these lines from the spec:

You don't need to specify all the super-tables if you don't want to. TOML knows how to do it for you.
[...]
Empty tables are allowed and simply have no key/value pairs within them.
As long as a super-table hasn't been directly defined and hasn't defined a specific key, you may still write to it.

These lines create the notion of implicit tables, that are created because "You don't need to specify all the super-tables if you don't want to. TOML knows how to do it for you."

But the output format does not have the notion of these implicit tables (as JSON does not distinguish this). So we need to keep the notion of implicitness around while parsing, because only implicit tables can be made explicit later, while redefining explicit tables results in invalid TOML.

Possible solutions:

• Change specification so all empty tables can be redefined. In this case an implicitly created table is simply an empty table. (breaks no existing TOMS files, as spec will be more lenient)
• Do not allow implicit tables to be explicitly defined. This effectively kills the notion of implicit tables. What are currently implicit tables are then just regular un-redefinable empty tables. (breaks some existing TOML files, spec will be more strict)

[ChristianSi]

@cies Your parser doesn't have to care for any of this stuff. A table is just a table, it does not matter one bit if it's implicit or explicit, written as inline table or in standard style. When writing a TOM parser, these different ways of writing a table should all be treated as equivalent.

And when writing a TOML generator, just emit tables in the form that's most convenient to you -- it's totally up to you which style to use.

[ChristianSi]

Ah, on re-reading I notice that I misunderstood your point and you complain that implicit tables make parsing more difficult.

Hmm, that may be the case but I still don't agree that the spec should be changed. Implicit super-tables are convenient for manually written TOML and that, I think, is more important than easy of implementation.

TOML quite deliberately makes different choices from JSON -- JSON is extremely easy to parse or emit by computer, but hard or read or write manually. TOML favors easy of use for humans over easy of parsing. It's a different choice but one that should be defended, I think.

And allowing "you may repeat a table name but only if the first section is empty" (allow empty tables to be redefined) would just be needlessly confusing.

[cies]

Ok. Thanks of the elaboration. I was just trying to see if "keeping the notion of implicitness around until finished parsing" is really needed. I guess it is, which is fine, we already have a spec compliant implementation.

Shall I close this issue @ChristianSi ?

[ChristianSi]

@cies:

Shall I close this issue @ChristianSi ?

Well that's up to you, you opened it after all ;)

But note that I just stated my personal opinion, I not "officially" involved with the toml project at all.

[mojombo]

I agree with @ChristianSi on this one. The idea of implicit vs explicit table definitions is important. TOML can protect you from mistakes with that notion, where you lose some of that if you allow redefinition of any empty table.