The eno notation language

From a relatively short glance, I don't see any mention of what problem this is trying to solve. Data interchange? Storage? Consumption/production?

I see some excitingly magical looking type "inference" happening though. That ruby code is sure that the value associated with Malaga is a lat/long pair is it? Not a temperature range, etc.? So, some very optimistic approach to types, no real way to validate content, and some quirky looking syntax (<key>: <value>, but also #<section>\n<key>: <value> apparently? If I have more than two levels?)

I'm not sure what this is for. I am pretty sure that those people using it are going to run up against a whole thrilling raft of edge cases...

  # cities
  Den Haag: 52.069961, 4.302315
  Málaga: 36.721447, -4.421291

Here, “cities” looks like a comment, but it is part of the syntax, otherwise this example code would not work:

  document.section('cities').lat_lng('Málaga')

The actual comment syntax is “>”:

  > comment

What non-indented markup languages gain by avoiding indentation, they lose in succinctness. What is the difference between a section, a list, and a field set? When would I use one instead of another?

If your aim is data representation, why not go for JSON, Lua table-notation or S-expressions? These do not need different syntax for sections, lists or field sets, but have very clear syntax for a few primary data structures, which you can them compose however you want.

A 50s demo video of autocompletion in Atom powered by introspection:

https://eno-lang.org/resources/introspection.mp4

This reminds me of an old project of mine called NIML - Non-Indented Markup Language.

http://mstijak.github.io/niml/index.html

Is there a comparison to TOML?

Thought this was about hammocks :(

INI files 2.0