The Eno notation language(eno-lang.org)
eno-lang.org
The Eno notation language
https://eno-lang.org/
32 comments
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.
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
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
> 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.
Please make this clear on the website! I think it’s a clever idea.
Also, this has garnered some attention on Lobste.rs [1], if you’re interested to read the discussion there as well.
[1]: https://lobste.rs/s/jno6gb/eno_notation_language_libraries
Please make this clear on the website! I think it’s a clever idea.
Also, this has garnered some attention on Lobste.rs [1], if you’re interested to read the discussion there as well.
[1]: https://lobste.rs/s/jno6gb/eno_notation_language_libraries
Thanks for that feedback! I'll see what I can do to communicate the API type concept better, I'm generally struggling to pack all the bandwidth of things into the little available prominent space on the website, but eventually I will get it right for most people I hope. :)
Also thanks for letting me know about the lobste.rs thread, I'll see that I get invited and answer the few not yet-answered points, couldn't get to it yesterday unfortunately amidst all the comment and issue and PR flood here and on github. ;)
Also thanks for letting me know about the lobste.rs thread, I'll see that I get invited and answer the few not yet-answered points, couldn't get to it yesterday unfortunately amidst all the comment and issue and PR flood here and on github. ;)
# cities
Den Haag: 52.069961, 4.302315
Málaga: 36.721447, -4.421291
document.section('cities').lat_lng('Málaga')
> commentYes 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. :)
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. :)
This is a really cool project! I don't need quite the power of eno (yet!) in my CLI journaling app[1], but I similarly value the power of users being able to just easily read and write their own data. (I went with Markdown for the data store.)
[1]: https://github.com/JacobEvelyn/friends
[1]: https://github.com/JacobEvelyn/friends
Thanks for the encouragement!
I like the philosophy of friends! (even though I too don't need quite the power of it (yet). ;))
I like the philosophy of friends! (even though I too don't need quite the power of it (yet). ;))
It looks like the H1 tag in markdown, where the number of #'s indicate title level.
Spot on, that's how it works!
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.
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.
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!
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!
A 50s demo video of autocompletion in Atom powered by introspection:
https://eno-lang.org/resources/introspection.mp4
https://eno-lang.org/resources/introspection.mp4
This looks like a cool project, but I don't know how I feel about the non-primitive type loaders. Date strings, email addresses, urls, colors, and lat-long are hard problems, and trying to handle them in the spec is a misstep. Leave the complex loaders out, strive to handle perfectly just the core list of primitives, and let devs write their own email or url parsers. (Who is asking for lat-long parsing?)
(Seriously, the email parser doesn't match most of the Examples [0] on the Wikipedia page about email validation. Don't use regex to validate unless you're gonna write `/.* @.*/`.)
[0]: https://en.wikipedia.org/wiki/Email_address#Examples
(Seriously, the email parser doesn't match most of the Examples [0] on the Wikipedia page about email validation. Don't use regex to validate unless you're gonna write `/.* @.*/`.)
[0]: https://en.wikipedia.org/wiki/Email_address#Examples
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. ;)
This reminds me of an old project of mine called NIML - Non-Indented Markup Language.
http://mstijak.github.io/niml/index.html
http://mstijak.github.io/niml/index.html
Pretty cool, I remember coming across it during research for eno actually! small internet :)
Is there a comparison to TOML?
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 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.
The `benchmarks` repo contains various sample files in yaml, toml and eno
https://github.com/eno-lang/benchmarks/
https://github.com/eno-lang/benchmarks/
I waiting for the day XML becomes hip again. Then we'll be able to rebuild all XML parsing tools.
Thought this was about hammocks :(
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 :)
Well, it doesn't look particularly intuitive, but it can't be worse than YAML.
JAMD (just another Markdown)
Oh, yay, yet another markup language (dammit, that's yaml, oops). More stuff to confuse people. Why did the world need this? Solving what?
Also, I thought at first it was "emo", then I thought it was referring to hammocks.
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...