The Eno notation language

In the latest years I've seen a trend towards syntax-lightweight languages.

Developers are already well served with their powerful programming languages, able to express very complex concepts and relations with terse syntax. But those high-level languages have very complex grammars, and each token must be carefully placed with respect to their surrounds to make sure that it compiles and expression types are well matched.

There's an unmet need at the other side of the complexity spectrum, with languages that can't express complex concepts, but which accept simple terms expressed with extremely simple syntax and grammar; to the point that non-programmers may be able to create and edit those files. For building documents we first had BBCode and now have Markdown as the emerging standard; but things like templates and simple scripting needs require a language which can express some computations and relations.

Developers first wrote ad-hoc parsers for their configuration files, and are now well served with JSON for structured data serialization. But that format is still too complex for casual use by inexperienced users. Something like eno could work for them in a context where defining data structures and assignment to variables is needed.

What you're seeing there is actually validation :), the lat/lng type is not magically inferred but instead explicitly requested by the code - if it were not valid it would generate a user-friendly, localized error message. Also the underlying document hierarchy that holds the data is validated. So on the contrary it is actually hard not to validate content in eno.

The quirky looking syntax you mention is probably familiar to you from YAML or paper forms ("Name: Joe"), and Markdown ("# Section"), likewise if you have two levels you use "## Subsection".

There's quite a few things that eno solves (there's only so much space on a frontpage, sorry), but if you want one of the more prominent ones: It's considerably hard to win over users without technical background to switch to secure, statically generated content solutions when the most prominent format works like this: http://yaml.org/spec/1.2/spec.html I've explained eno in 5mins to a non-technical intern who is now managing content at a client of mine and in months I haven't heard a single question about how eno works! User empowerment. <3

It looks like the H1 tag in markdown, where the number of #'s indicate title level.

Yes exactly - Hashes denote 'sections' in eno!

In the language design phase this was heavily inspired by markdown, because of the already widely familiar concept of 'headings' - I collected feedback from users that (although they showed considerable anxiety given the prospect that they were to use text files to edit their content in the future instead of a fancy web interface) they found working with markdown (quote) "super easy", so markdown was therefore an influential factor for some aspects of the language design. :)

section vs. list in eno is like object vs. array in JSON - you need both.

eno has neither indentation nor closing tags of any sort, that means if you use a section to group some values, you need to start another section to end the previous one (no closing tags!), that's why there are fieldsets, which allow short groupings that automatically end with the next field/list/fieldset.

I share your opinion that a single syntax would be the ideal thing, but not having closing tags (which keeps the language simple and fast to write) required a trade-off in the language design to be made.

Why not JSON, Lua table-notation or S-expressions? Because the prime design goal was to achieve greatest possible simplicity and accessibility - almost anyone should be able to use it, no matter the background. If possible I would have wanted eno to be even more reduced and simple, but at some point you have to draw a line too, otherwise you end up with a toy, and then you won't ever get adoption by devs either. So this is why eno ... :) Thanks for your question!

Mention of atom and the fifties caused me to hallucinate Fallout-style atompunk/Jetsons retrofuturism.

I fully agree with your assessment - eno allows arbitrary types, therefore if and to what extent non-primitive type loaders should be included as core functionality needs to be thoroughly considered and negotiated soon. I included non-primitive loaders (also the exotic lat/lng ;)) to (a) show that this is a possibility and (b) get hands-on insight how well this works in real world usage. (in short: I love it so far, but I'd love to hear other experiences!) It took months to get the whole ecosystem jump-started as a one man show, so that's why some loaders are ... pragmatically coded, you're of course right on that, although admittedly I had no idea the email spec was that complex, thanks for making me aware. ;)

Pretty cool, I remember coming across it during research for eno actually! small internet :)

The `benchmarks` repo contains various sample files in yaml, toml and eno

https://github.com/eno-lang/benchmarks/

I'll attempt to list some major points: - TOML keys are alphanumeric, in eno they allow the full unicode range - In eno there are no inline syntax constructs like in TOML, this is simpler although sometimes more verbose - TOML has fixed types and type syntax rules on the language level, eno has arbitrary application-defined types - TOML is designed for completely generic de/serialization (through fixed types), eno relies on domain-specific serialization

There are also (maybe even more) important paradigmatic differences concerning how the parser APIs differ, and also need to differ, given the different typing approach in TOML vs. eno, but I'll limit this to the language points for brevity here. :)

Generally speaking - the higher the volume of content/configuration/data there is in a given application or the more it is relevant that the application is also accessible and easily usable for users without a technical background or the more your data and types are application specific and possibly exotic, the more I would recommend eno.

On the other hand, the more generic your data (especially the more it requires generic serialization), the more it is shared by myriads of different applications, the more it is handled by a very technical audience, the more I would recommend TOML.

There is considerable shortage of available three-letter file extensions that don't sound like robots from star wars, so unfortunately a sacrifice had to be made there :)

I agree, the feature set seems largely inspired by INI files. It seems in general there is a large demand for a more flexible (and less ugly) version of INI files.

Wouldn't that be TOML?