kowainik / tomland

🏝 Bidirectional TOML serialization
https://kowainik.github.io/posts/2019-01-14-tomland
Mozilla Public License 2.0
120 stars 39 forks source link

[RFC] Different TOML AST #264

Open chshersh opened 4 years ago

chshersh commented 4 years ago

An idea I had in mind for a while, but not sure, whether it's better or worse. Currently, the TOML type looks like this:

data TOML = TOML
    { tomlPairs       :: !(HashMap Key AnyValue)
    , tomlTables      :: !(PrefixMap TOML)
    , tomlTableArrays :: !(HashMap Key (NonEmpty TOML))
    }

What if instead of this representation, we will use another one:

type TOML = PrefixMap TomlEntry

data TomlEntry
    = Val AnyValue
    | Table TOML
    | Array (NonEmpty TOML)

A general ideas is that we don't distinguish between different key types, instead we distinguish different types of entries.

Costs

Benefits

  1. Uniform handling of keys, tables and arrays.
  2. Easier to check, whether there's a conflict between keys
  3. Should be much easier to implement features like #223 #261
  4. Questionable benefit: A new representation look more elegant
chshersh commented 4 years ago

At this stage, this will require to rewrite a lot of code, and I don't see a reason to do this without compelling use-cases. They may appear in the future, but the current design works so far. The proposal is just a different design, and it's not yet proven as a better design.

chshersh commented 3 years ago

We may change AST even further to be able to preserve the initial ordering of fields. This may be useful in the situation when you want to change some parts of TOML programmatically, but keep the original formatting for a minimal diff.

Probably, preserving the entire original formatting would be too big and a challenging task. But keeping the original order of fields shouldn't be that difficult. Though, we need to keep this in mind when we decide to change AST.