This looks surprisingly nice, which is a high bar to clear when it comes to my opinion of new config file formats.
Am I understanding correctly that this basically adds a type system to TOML? Have you considered calling it TypeTOML and making it a superset of TOML? (Maybe this is covered in the readme which I only skimmed.)
It would be cool if I could rename `config.toml` to `config.ttoml` and add types as I need them, similarly to how I can rename `script.js` to `script.ts` for iterative adoption of TypeScript. Although obviously this would require the consuming code to implement the Jesth (TypeTOML?:)) parsing, which would maybe defeat the point of iteratively adopting it (why bother with partial compatibility then?). Perhaps you could make it a _compatible_ superset, with types implemented using TOML comments so that existing TOML parsers can parse an (untyped) structure from a Jesth file by ignoring the comments, while Jesth can parse a typed structure from the same file.
I remind you that any comparison with TOML, JSON, or YAML only concerns one of the capabilities of Jesth, namely the ability to convert a compatible section into a dictionary data structure.
A Jesth document may not have a section intended to be converted into a dictionary data structure. Therefore Jesth can be used e.g. as a markup language for docstrings (My closed-source documentation generator parses the source code to populate the 'docs' folder of my projects with Markdown files [1])
Therefore, the lines below are for Jesth sections intended to be converted to a dictionary data structure.
There is currently no type system, that is, a mechanism to ensure that values assigned to a certain key always conform to a specific data type. I'm thinking about it. Think about how we create relational database tables with SQL.
Jesth is not going to be a TOML superset, they have incompatible underlying philosophies. For example, the design decisions behind Jesth accidentally created an unlimited pool of reserved words (headers with double square brackets on either side are reserved words), from which I used [[END]] to mark the end of a Jesth stream. TOML currently doesn't have such a thing since they already use these double square brackets on each side for something that is trivially done in Jesth.
Am I understanding correctly that this basically adds a type system to TOML? Have you considered calling it TypeTOML and making it a superset of TOML? (Maybe this is covered in the readme which I only skimmed.)
It would be cool if I could rename `config.toml` to `config.ttoml` and add types as I need them, similarly to how I can rename `script.js` to `script.ts` for iterative adoption of TypeScript. Although obviously this would require the consuming code to implement the Jesth (TypeTOML?:)) parsing, which would maybe defeat the point of iteratively adopting it (why bother with partial compatibility then?). Perhaps you could make it a _compatible_ superset, with types implemented using TOML comments so that existing TOML parsers can parse an (untyped) structure from a Jesth file by ignoring the comments, while Jesth can parse a typed structure from the same file.